Messages in this thread | | | Subject | Re: [PATCH] automatic initcalls | From | Keith Adamson <> | Date | 29 Jul 2002 22:51:07 -0400 |
| |
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] | |