I worked with an embedded operating system some years ago that did 
exactly this.

There was a "module configuration" file which listed 
prerequisites.  Modules could be requested by name or by "tag", and 
modules could claim to satisfy a requirement (allowing things to be 
stubbed out).

Then each module that wanted initialization services had a macro that 
specified an init function (by name).  The name got mangled in a 
recognizable way and put into the symbol table.  The build process 
would link twice, once to get the symbols (ld -r or equiv), scan to 
find the magic symbols, and use the module topological sort to build 
an init vector.

This seemed better than implicit initialization, because there are 
subtle problems with cycles in the initialization graph, which are 
more readily resolved by an engineer than by a machine.

Anyway, the result was a system without a main() function, which made 
updates and modular additions really easy.  LKM-like things were 
faked by calling the INIT-entry point (of course the things you 
depended on had to be in the kernel, and it was your job to make sure 
of that; this was in the late 80s).

So I can recommend this approach, for whatever it's worth.

--Terry

At 05:20 PM 11/22/2005 -0500, Steven M. Bellovin wrote:
>In message <20051122215324.GB24186@netbsd.org>, Bill Studenmund writes:
> >
> >
> >
> >How do you think we should encode dependencies? I agree that the FreeBSD
> >way is uncentralized. However someone who studies the whole system can
> >tune it so that things get loaded in the right order (just pick the right
> >set of "FIRST", "SECOND", and so on). How would we do that w/o the master
> >list of values?
> >
>Thinking out loud -- something like rc.d uses?
>
>                 --Steven M. Bellovin, http://www.cs.columbia.edu/~smb