Folks,

pool_init(9) lists its 5th argument as "int nitems":

           nitems        Specifies the number of memory items that are allo-
                         cated to the pool at creation time.  This number may
                         be zero, in which case pool_prime() can be used at a
                         later time to add permanent items to the pool.

However, the function itself in kern/subr_pool.c has "int flags" as
its 5th argument.  The only flags that are used in the field that
is initialised with argument this are PR_PHINPAGE and PR_LOGGING.
PR_LOGGING is set automatically if the kernel option POOL_DIAGNOSTIC
is defined and appears to be useless if that option isn't defined
so it's use as an argument to pool_init() also appears useless.  If
PR_PHINPAGE, an internal field saying where the pool header is, is
passed to pool_init() and the pool_init() code sets up the pool header
in what it thinks is one place and this flags tells later code that
the header is in another place, Bad Things can happen.


I can see two ways to deal with this:

 1)  Change the pool_init() code to use the argument as nitems as the
     manual page states.  This may or may not require a kernel version
     bump.  Just about all uses of pool_init() (except a handful in
     raidframe) use 0 for this argument.  The raidframe code makes the
     mistake of following the man page :-(

 2)  Remove the fifth argument altogether.  This would obviously require
     a kernel version bump.

I think I prefer choice 1.  Any opinions?

Simon.
--
Simon Burge                                   <simonb@wasabisystems.com>
NetBSD Development, Support and Service:   http://www.wasabisystems.com/