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

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

> Date: Fri, 23 Oct 2026 09:48:40 -0700
> From: Jason Thorpe <thorpej%me.com@localhost>
> 
> > On Oct 23, 2026, at 9:37 AM, Taylor R Campbell <riastradh%NetBSD.org@localhost> wrote:
> > 
> > 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.
> 
> Counter-argument: Use of a ctor guarantees that the object will be
> returned to the caller in the constructed state.

No, it doesn't?

Given

	ctor(obj) { obj->foo = 1; }

the following can print either 1 or 2:

	obj = pool_cache_get(pc);
	obj->foo = 2;
	pool_cache_put(pc, obj);

	obj = pool_cache_get(pc);
	printf("%d\n", obj->foo);

There _may_ be a dtor/ctor cycle between the pool_cache_put and the
pool_cache_get, but there's no _guarantee_ of that.

The only guarantee is that when a _backing page_ is allocated, the
ctor will run before pool_cache_get returns any objects from it, and
after pool_cache_put, the dtor will run before its _backing page_ is
freed.

In contrast, the proposal with PR_ZERO is to guarantee that it prints
0, every time.