Hi,

While adding CPU level caches to pool_cache on the vmlocking branch, I also
changed the interface to be more LKM friendly. I need to give invalidation
the ability to drain caches on remote CPUs, but once that is done I'd like
to merge these changes into -current (but with the MP locking stubbed out
for now, some users of the interface will trigger lock assertions).

The changes are:

1. Caches are dynamically allocated so that users don't need to worry about
   internal changes. The idea is that pool_cache should become the public
   slab/object allocator that device drivers / LKMs use, and the pool
   allocator should be for "kernel internal" use.

   pool_cache_t
   pool_cache_init(size_t size, u_int align, u_int align_offset,
      u_int flags, const char *wchan, struct pool_allocator *palloc,
      int ipl, int (*ctor)(void *, void *, int),
      void (*dtor)(void *, void *), void *arg)

2. It's no longer possible to associate multiple caches with a single pool
   This is not something that has been used to date, and it added complexity
   to the interface and the implementation.

3. In addition to pool_cache_init(), there is also a pool_cache_bootstrap(). 
   This is used by the VM system to set up static caches before it is
   possible to allocate memory. Since these calls are in the guts of the
   kernel, they don't need to worry about changes to pool_cache internals -
   a recompile solves that.

4. A number of calls are added that pass through to the pool that's backing
   the pool_cache, e.g. pool_cache_set_hiwat() -> pool_sethiwait().

5. If 'palloc' is NULL when creating a pool_cache / pool, then pick a
   default allocator based on the value of 'ipl':

	ipl == IPL_NONE -> pool_allocator_nointr
	ipl != IPL_NONE -> pool_allocator_kmem

Comments?

Thanks,
Andrew