Chris G. Demetriou wrote:
> uh...
> 
> (1) i don't know why you couldn't declare things in a module-specific
> header, then use them where needed.
> 
> (2) i actually just grepped in a 4.0 kernel source tree, and found:

Hmm, I have mistaken then, sorry. I recalled this bit just from memory
and it was prolly bad.

> So, I think either you're mistaken, things have changed for the worse
> in their current sources, or i'm badly missing something.  Another way
> of looking at it: "do you have an actual example of a problem, or is
> this just FUD?"

It's not meant to be FUD, FWIW.

> Uh, I'd disagree that it's good programming style, at the very least.
> 
> In general, it's good programming style to keep module-specific data
> and definitions in one place, close to the module.

That's sure true.

> The existing way
> NetBSD does things makes that effectively impossible (and creates
> extra maintenance work, too).

Is the amount of "extra maintanence work" really so bad to warrant
addition of the *DEFINE() hackery ? Doesn't that boil down just to
"they do it differently then what we are used to" ?

Such dynamic scheme just looses when one need
to find out "who defined malloc type 459"-type of information.
I don't have enough experience with debugging code using such dynamic
scheme to say whether this really matters or not. I kind of like
when globally used information is kept centralized.

> Perhaps the right thing, then, is to force hand-crafted init code to
> add each malloc type, etc., as needed.  However, it seems wasteful and
> still causes unnecessarily maintenance (why do it by hand when you can
> get the compiler/linker to do it for you)?

Sure, hand-crafted init code is not really better than the *DEFINE()
magic :)

BTW, is it really needed for malloc ? Shouldn't the code use
pools for "permanent" stuff and M_TEMP for temporary ? ;-)
 
Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>      http://www.ics.muni.cz/~dolecek/
@@@@  Wanna a real operating system ? Go and get NetBSD, damn!  @@@@