Hi, On Mon, 22 Jun 2009, Greg KH wrote:
But that's really just to address dependencies, right? I don't intend to load the modules at the same runlevel where they would have run if normally compiled statically. If we load the linked module after the usual static parts have initialized, then we'll still observe the dependencies.
No, it's to tell the kernel exactly when to initialize the code at what part during the init level processing, and link order matters.
"exactly when to initialize the code" == "addresses dependencies", isn't it?
Actually, in thinking about it some more, I don't think this is going to work properly for the "fastboot" stuff that we really need. Here's why:
- When drivers are build into the kernel, they are initialized in the order in which the Makefile places them, and we build them in pretty early. This allows the drivers to start up, and do some async stuff while the rest of the kernel initializes.
Excuse me for not being up-to-date wrt. the kernel anymore, but isn't this done via the .init sections?
- If you somehow "link" the modules into the built kernel, you will have to set up a mechanism to call the module_init() calls. The only safe way to do that is at the end of the init cycle. So any async processing that could have happened, will not, as these drivers will be the last things in the boot process now, instead of very early like they used to be.
... Because if it is, then linking modules into the built kernel after the fact isn't going to change this principle. You still have a .initcall section (well, two of them, one for the built kernel, one for the module lump) which the kernel proper would iterate over very early (after determining existence of the second initcall table). Ciao, Michael. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org