Subject: pool_init() and it's 5th argument
To: None <firstname.lastname@example.org>
From: Simon Burge <email@example.com>
Date: 12/21/2003 18:42:53
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 Burge <firstname.lastname@example.org>
NetBSD Development, Support and Service: http://www.wasabisystems.com/