> Just FYI, FreeBSD is contemplating changing our API one more time to have
> timeout take a callout handle.  This will allow us to get rid of the
> static allocation of callout entries (which you could also do simply by
> tacking on the use of a pool or zone allocator to the current FreeBSD
> interface), but more importantly, will allow clients to perform upfront
> allocation of callout resources rather than add complicated error recovery
> for failed allocations in an interrupt context.

I once worked on a standalone crt0 layer that had many optional features
and needed its own atexit() system, and I must say that the caller-allocates
model is far superior any time it does not conflict with something else you
need to do.

For instance, what if the caller-allocated memory is in an LKM? Now you need
to be sure that LKM memory is not freed until the LKM has done a proper
shutdown. Since this is probably already true, then no problem. But:

The other thing I considered this for was for network stacks that would
run on top of a firmware-based debugging port (which was ethernet), and
things are not as simple there. Until you know who the packet is for, you
can't drop it in the right buffer, so you are forced to do copies (or to
not unload any modules that have given you buffers which are still on the
network hardware's receive queue).

(In principle, PIO-only ethernet hardware would also get around this, but
I don't really consider that a solution.)

Todd Whitesel
toddpw @ best.com