i386. Stop abusing it on other archs for controling a shutdown by
pressing the soft power button:
* Add a MI sysctl hw.allowpowerdown; if set to 1 (the default) it
allows a power button shutdown.
* Make acpi(4)/acpibtn(4) honor hw.allowpowerdown.
* Switch the various power button intercepts on landisk, sgi, sparc64
and zaurus over to hw.allowpowerdown.
* Garbage collect the machdep.kbdreset sysctl on all archs other than
amd64 and i386.
ok miod@
* Instead of nesting subshells, perform a linear series of operations
and bail out as soon as one of them fails.
* Rename rc_print to rc_exit, let it calculate the exit code itself
and let it exit, considerably simplifying error handling; new name
suggested by sthen@.
OK ajacoutot@ sthen@
disks and scsi id#3 as the boot device, by all means, use DUIDs to mount your
filesystems and it won't matter what sd unit number the boot disk attaches with.
the correct code according whether the daemon did start successfully or
not.
rc_wait()
This function has been extended, first we need to pass in which mode we
are running (start or stop) and second we can pass a number of seconds
to wait (optionnal, will default to 30s).
The function will return the correct code whether we are running during
"rc_cmd start" or "rc_cmd stop".
rc_cmd() start
If we are running in background mode, then we call rc_wait with the
"start" argument.
The sleep(1) is needed to prevent a race condition where the process
will appear in the list before failing and rc_check will see it as
running. Call rc_post() when failing to prevent being left in an
inconsistent state (because rc_pre() would have run successfully)
rc_cmd() stop
We are now calling rc_wait with the "stop" argument.
"looks good" sthen@, ok robert@
Doesn't matter much since C++ ABI used by GCC doesn't mangle variable
names; however technically is required by Section 7.5 of the C++ spec.
Discussed with/OK guenther@, matthew@.
position zero, skipping a random number of free slots and then
picking the next free one. This slowed things down, especially if
the number of full slots increases.
This changes the scannning to start at a random position in the
bitmap and then taking the first available free slot, wrapping if
the end of the bitmap is reached. Of course we'll still scan more
if the bitmap becomes more full, but the extra iterations skipping
free slots and then some full slots are avoided.
The random number is derived from a global, which is incremented
by a few random bits every time a chunk is needed (with a small optimization
if only one free slot is left).
Thanks to the testers!
martynas