Re: CVS commit: src/sys/dev/usb

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Fri, 23 Oct 2026 09:07:24 -0700
> From: Jason Thorpe <thorpej%me.com@localhost>
> 
> > On Oct 23, 2026, at 8:33 AM, Taylor R Campbell <riastradh%NetBSD.org@localhost> wrote:
> > 
> > Maybe PR_ZERO should be an option to pool_cache_init rather than to
> > pool_cache_get?  (And pool_cache_get should assert that it is _not_
> > set.  Also pool_cache_init can assert that ctor/dtor is mutually
> > exclusive with PR_ZERO.)
> 
> Alternatively, there could be a magic constructor function value that could specify zero-on-allocate, since PR_ZERO and having a constructor are really mutually-exclusive.  
> 
> int
> pool_cache_ctor_zero(void *arg __unused, void *obj __unused, int flags __unused)
> {
>     return 0;
> }
> 
> …then in pool_cache_get_paddr(), before “object” is successfully returned:
> 
>     If (__predict_false(pc->pc_ctor == pool_cache_ctor_zero) {
>         memset(object, 0, pp->pp_pool->pr_reqsize);
>   }
> 
> Could even specify a magic destructor if you want to zero-on-free (e.g. security-sensitive uses).

I think a flag is clearer than a magic ctor/dtor.  The point here is
to change the behaviour of pool_cache_get (or pool_cache_put), but the
ctor/dtor explicitly _do not generally_ run on pool_cache_get/put (a
common misunderstanding I have seen, and had myself in the past).
Using them for this role seems likely to be even more confusing.