lkml.org 
[lkml]   [2002]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] automatic initcalls
From
Date
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 :)



[unhandled content-type:application/x-tar]
\
 
 \ /
  Last update: 2005-03-22 13:27    [W:0.064 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site