Jun-ichiro itojun Hagino <itojun@iijlab.net> writes:
> 	okay, you may be able to reuse symbols.  however, that would degrade
> 	readability.  if we see M_FOO in one module and M_FOO in another, I
> 	expect them to refer to same mbuf type, not different one.
> 
> 	and if you mean reusing actual numbers (not symbols), how do you gather
> 	statistics based on mbuf type, if you use duplicated number on them?
> 	I love vmstat -m.

the point is, _none_ of this should be 'number' based, where that
number is an index into an array of count structures.

I don't think i get your point about vmstat -m.  It's possible to do
the exact thing that vmstat -m does, if the M_* type structures are in
a linked list in the kernel... and that doesn't kill extensibility.

at the worst, this discussion becomes absurd.  What if some random
file system wants to define 'struct inpcb'?  well, surely that'll
confuse some people...  Does that mean that we should put every single
header in the source tree in sys/sys, or that there should only be one
single header file at all?  8-)


Is there some specific problem that changing the M_FOO types to be
pointers to structures would cause?  if so, please present it with
source references.


> >>	I believe centralized management in
> >> 	sys/sys/malloc.h is good enough.
> >Look at the list above.
> >You'll note that 'M_AFS' is there.
> >The one definition, in itself, is proof that centralized management in
> >sys/sys/malloc.h is _not_ good enough.
> 
> 	I'm just fine with M_AFS...

perhaps you've missed the point, or perhaps you've ignored it.

NetBSD has never shipped AFS.  It may not ever ship AFS.

The M_AFS constant was put there, in a nutshell, to ease the pain of
people who maintain(ed) the AFS LKM for NetBSD.

It was painful for them to have to keep shippping diffs to malloc.h,
and to require that users apply them to their kernels before
attempting to use the AFS LKM.

It should be plainly obvious that, if a kernel's interfaces are
structured reasonably, somebody wanting to add an LKM shouldn't have
to apply diffs to the non-LKM portion of the kernel to do it.  It
should also be obvious that you wouldn't want M_AFS to be lumped in
with, say, M_TEMP.

The fact is, as recently as a month ago, i've received complaints
about this specific type of problem from people doing systems-level
work on top of NetBSD.


Even if one were to grant that M_AFS, all by itself, is fine, what do
you then do when there are 50 more similar cases?  (indeed, why should
somebody who doesn't have modules that go with most of the malloc
types in malloc.h waste space for _their_ type-specific counter
information.)



cgd