I propose the following changes in the pool(9) interface, to make it
more useful in a number of situations. The main idea is to provide
the ability to customize the allocation and deallocation of 
memory that is being managed by a pool, instead of just using
malloc/free.

Doing that raises the issue of dealing with individual chunks
returned from the pool when it has been over its "high water" mark.
Requiring a custom deallocation routine to do additional bookkeeping
would probably annihilate the benefits of having a common pool manager.

Instead, a pool can allocate memory in larger chunks (e.g. page-sized)
that are easy to deal with by the underlying allocator. Internally,
the pool routines divide these pages up in pieces that have the
desired pool item size. It'll keep track of the page to which
individual pool items belong. Pages can be returned to the underlying
allocator (when over "high water") when all pool items associated with
it have been returned to the pool.

A drawback of this approach is that there is no guarantee that a pool
will get back to its nominal size because of fragmentation of pages
that might persist. This is dependent on the usage patterns of the
pool itself. This is not an issue with drivers using a pool to setup
I/O (e.g. the swap device, vnd, ccd, etc.) which should have a bounded
turn-around time. Other candidates for using pools may hold on to
pooled memory longer, e.g. a pagetable memory pool I experimented with
a bit for use by the pmap functions.