and adjust the path in the Makefile for the upgrade_checks target.
These checks are really feature upgrade checks that should be fast
and just find out whether we need to build a new make before
proceeding with other targets like buildworld. This makes the
place free for a real regression test suite in the old place.
http://www.ambrisko.com/doug/listio_kqueue/listio_kqueue.patch
Note: it is a good idea to run this against a physical drive to
exercise the physio fast path (ie. lio_kqueue /dev/<something safe>)
This will ensure op's counting per LIO request is correct. It is
currently broken the above patch fixes it.
Sponsored by: IronPort
against a disk as the argument. If you don't it will use a temp file.
The raw disk will use the kernel physio fast path method until the
max number of pending op's is reached then it will queue them. File
system op's are always queued. This is more important with LIO since
operation can get split across and accounting of op's is broken with LIO.
Note that this was broken when locking was added to kqueue (ie. 5.3)
My fix needs to be better integrated with FreeBSD.
Next is an LIO test and implementation.
Sponsored by: IronPort
modules to rip out the available sysctls. It will then produce a manual
page which may be installed with 'make install'. Currently typing 'make'
in the directory uses the default /boot/kernel files. To use a specific
directory, run sysdoc -k [location].
- Use fesetround() instead of fpsetround(), and add tests for
various rounding modes.
- Test that all NaNs generated are quiet.
Some of these tests won't pass until problems in vendor sources
(gdtoa and gcc) are fixed and new versions imported, but I
want to get these changes into the tree before I accidentally
blow them away again. :-(
tests. (Buy 10, get one free!) The separate categories were
already there; they just weren't labeled.
- Use fesetround() instead of fpsetround(), since the former is
standard and implemented on all supported architectures. Add
tests for each rounding mode.
- Add additional tests for subnormals.
Some of these tests won't pass until problems in vendor sources
(gdtoa and gcc) are fixed and new versions imported, but I
want to get these changes into the tree before I accidentally
blow them away.
introducing the disk formats for _RuneLocale and friends.
The disk formats do not have (useless) pointers and have 32-bit
quantities instead of rune_t and long. (htonl(3) only works
with 32-bit quantities, so there's no loss).
Bootstrap mklocale(1) when necessary. (Bootstrapping from 4.x
would be trivial (verified), but we no longer provide pre-5.3
source upgrades and this is the first commit to actually break
it.)
bind()/connect() system calls, which is intended to confirm that the
right successes and errors occur when rendezvousing via the file system
name space.
and as long as we're not compiling with IPA, gcc(1) won't optimize
the call away. The whole purpose of using memcpy(3) is to avoid
misaligned loads and stores when we need to read or write the value
in the unaligned memory location. But if gcc(1) optimizes the call
to memcpy(3) away, it will typically introduce misaligned loads and
stores. In this context that's not a good idea.
60. The postinc store tests currently fail (value mismatch). Hence
the score as of this commit is 48 out of 60. Either the kernel or
the tests need to be fixed.
the given providers. Without even one of the configured components there
should be no way to get the secret.
Supported by: WHEEL Sp. z o.o.
http://www.wheel.pl
cleaned up; just wanted to make a place holder. The biggest issue is
that it is an incomplete revamp; that is... the inconsistent naming
table generation is not done yet ... will be added soon with the clean
up. The purpose of this script is to handle the vop_vector changes that
phk@ did over the recent weeks.
float, double and long double types. No post-increment tests yet.
All tests are skipped if the debug.unaligned_test sysctl variable
cannot be set to 1.
as they are the setrunqueue() and sched_add() calls. Since they happen
immediately before the thread is placed on a run queue they would normally
dwarf the more informative preemption or yield event and it is implicitly
understood that a thread is back on the run queue as part of these events.
