frank@wins.uva.nl (Frank van der Linden) writes:
> That was my first thought as well when .init sections came up: "what
> about ordering"? Ordering is very important, and not knowing the order
> is, as Itojun says, a debugging nightmare.
> 
> It might seem like a cool idea at first, but I'd rather see explicit
> init calls, at least it's clear what's happening then.
> 
> Ever tried to debug a C++ application with global constructors?

this isn't a problem where you're actually trying to do 'significant
stuff' in the constructor.

this is a case of 'add it to the {linked list,hash table,tree}'.


I'd there are actually significant ordering constraints there
(i.e. anything more than simple within-.o parent/child relationships,
for e.g. event counters), then either you want to use a more explicit
mechanism, or you want to reexamine your data structures to figure out
how exactly you screwed them up.  8-)

at minimum, OK, fine, don't go the 'automatically initialize' route --
provide code to do it.  but please:

	(1) make the bits dymically added/initialized, not tables, and

	(2) if possible, provide a way to reclaim the memory
	    afterwards, i.e. don't scatter it throughout the bloody
	    kernel object, put the init code in special sections, so
	    that if you've got enough you get pages back (if it's not
	    too hairy for the MD code to cope with).


cgd