done by Artur Grabowski and Thomas Nordin for OpenBSD, which is more
efficient in several ways than the callwheel implementation that it is
replacing. It has been adapted to our pre-existing callout API, and
also provides the slightly more efficient (and much more intuitive)
API (adapted to the callout_*() naming scheme) that the OpenBSD version
provides.
Among other things, this shaves a bunch of cycles off rescheduling-in-
the-future a callout which is already scheduled, which the common case
for TCP timers (notably REXMT and KEEP).
The API has been simplified a bit, as well. The (very confusing to
a good many people) "ACTIVE" state for callouts has gone away. There
is now only "PENDING" (scheduled to fire in the future) and "EXPIRED"
(has fired, and the function called).
Kernel version bump not done; we'll ride the 1.6N bump that happened
with the malloc(9) change.
mechanism by keeping a list (bitset) of which timers have fired and using
that list in the upcall (Does this sound familiar? SEND HELP NEED SIGINFO).
Provoke the idle LWP into running again with setrunnable(sa->sa_idle)
instead of a wakeup() call, since we know what it is.
being woken up by the the reaper when a child process is cleaned up
(SIGCHLD will still cause this to run, and threads actually waiting
for the child will still see the wakeup, of course).
Should fix various spurious wakeups that manifest as assertion
failures in pthread__idle().
* do not set *vpp unless successful, otherwise we'd trigger
DIAGNOSTIC panic in lookup(9) on error return
* on error, make sure to free malloc'ed memory and ungetnewvnode() the
previously acquired vnode
this fixes panic on 'tail -f <file> &; ls -l /proc/$!/fd' reported by
Andrew Brown
fix reviewed by Christos Zoulas
utrapframe that fixed in size (and the same size as the trapframe
in NetBSD 1.5). This preserves binary compatibility for those programs
that dealt looked at sigcontexts.
an iso-image created from the resulting release won't boot. I don't
know if this change is the source of that, but one more knowledgable
than I about the x86 booter needs to look at this, and I don't want
the waters muddied any more than necessary.
atatat