Jun-ichiro itojun Hagino <itojun@iijlab.net> writes:
> >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?

Personally, i would say that putting module-specific definitions with
those modules _increases_ code quality and readability.


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

This is great.  "There's a problem, I can't describe it, I can't tell
you how to repeat it, I can't repeat it myself, but it's Really Really
Bad?"

Without knowing what the specific problem is, I can't even begin to
fathom its cause, and whether that cause is a programming or design
error in their interface, a programming error in the code which uses
it, or what.  Without knowing that, it's impossible to know how to
make the design more bulletproof.


Personally, I think that automatic initialization is the way to go.
However, failing that, how about a scheme similar to theirs without
automatic initialization?  (i.e., code can declare and define
particular malloc types, which get turned into structures.  at module
init time, the module is responsible for 'attach'ing them to the
malloc code, etc.  module-specific headers declare malloc types,
module-specific files define them, etc.)



cgd