Re: [PATCH] automatic initcalls

[Keith Adamson <keith.adamson@attbi.com>]

[-- Attachment #1: Type: text/plain, Size: 2387 bytes --]

On Mon, 2002-07-29 at 22:49, Keith Adamson wrote:
> On Mon, 2002-07-29 at 04:39, Ingo Oeser wrote:
> > On Sat, Jul 27, 2002 at 11:51:32PM -0400, Jeff Garzik wrote:
> > > I've always preferred a system where one simply lists dependencies [as 
> > > you describe above], and some program actually does the hard work of 
> > > chasing down all the initcall dependency checking and ordering.
> > 
> > So we just need to build a directed graph, detect edges without
> > existing nodes (someone changed the initcall, we depend on) and
> > cycles (someone messed up the ordering) as errors, sort the
> > resulting graph toplogically and dump it as a sequence.
> > 
> > This is no rocket science and we have two tools, which does this
> > all for us (make and tsort, which create a warning for both cases).
> > 
> > The hard part is to CREATE all the dependencies and check and
> > double check them with the maintainers.
> > 
> 
> I definitely agree the easy part is the algorithm and the hard part is
> creating the dependency list.  For instance, attached is a small
> algorithm that does the initcall sequencing at run time.
> 
> The API is is simple, you just register your initcall with a list of
> critical initcalls you need to be run before yours (not all, just the
> ones you definitely need to be run first).  Then the ordering of the all
> the initcalls are sequenced at run time.  This way you don't have to
> worry about link ordering or code ordering of your initcalls during
> make/compile/link.  All initcall ordering is done during boot.  
> 
> This really frees you from module inter-dependencies because is doesn't
> mater in what order you register you initcalls.  You only need register
> them with a list the critical modules that need to be initialized before
> yours.
> 
> The API also provides that you can register more than one initcall for
> your module with a different set of critical modules that must be run
> first.
> 
> This should be relative easy to add to the kernel, as you don't have to
> modify any of the existing initcalls.  You do need to remove all
> existing calls to them and register them instead with the new API.
> 
> Untar and "cd init; cc *.c; ./a.out"
> 
> Four example modules register their initcalls, "foo1, foo2, foo3, foo4",
> and then the main routine sequences them at run time.  
> 
> Regards, Keith
> 
> 
Forgot the attachment :)




[-- Attachment #2: init_020729.tar --]
[-- Type: application/x-tar, Size: 10240 bytes --]