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

	I see,

>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-)

	no.  but why do we need to degrade readability than current state?

>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 don't think there's problem in making M_FOO not an index to
	fix-sized array.

	please show me how you would solve this, I just don't like the current
	freebsd way of doing this (if you make mistake in include file ordering
	kernel compilation fails in very non-intuitive way - I don't remember
	how to repeat my problem).  I just put my personal vote for current
	netbsd way than current freebsd way.  I still have no opinion about
	what you would propose.

(snip)
>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.)

	hmm.  I see your point.  the same problem as hardcoded device major #.

itojun