-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Matz wrote:
Hi,
On Tue, 23 Jun 2009, Greg KH wrote:
Excuse me for not being up-to-date wrt. the kernel anymore, but isn't this done via the .init sections? Yes it is, but order within the .init sections matter.
Yes, understood. This is determined by the link order. There is no reason that the hypothetical lump-modules-together-and-attach-to-vmlinux program cannot also observe some ordering given from the outside. In fact part of this program will be calls to the normal linker to join together the individual .o files of modules (possibly after stripping away some uninteresting sections), and that again establishes a certain order in the newly created initcall section. That's the point where you turn knobs to start some things earlier than other things, much like you right now had changed the order in the Makefile.
This is an interesting point. I've, so far, just been using the linker directly and accepting that the new objects would probably just end up getting appended in the order provided on the command line. I suppose it would be possible to interleave them.
If you build any code as a module, any of these different levels all change to be the "generic" module_init() call, which runs after all of these 8 levels runs. So you can't work backwards and figure out what level of init call the module really wanted to be run at if you only have a .o file.
... maybe you can't currently, but we are talking about ways to improve the sitation. One of the necessary things would be to _not_ throw away this information. You would then end up with multiple .initcall sections also in modules. That's perfectly fine if the module loader simply iterates over all of them in order. The linker script can make sure that all these .initcall sections are lying next to each other (i.e. just remain separate in the ELF section list), so that the current code doesn't even need to be changed, if I'm reading it right.
The linker script does this now, but it also consolidates them into one .initcall section. AFAIK the only down side to not consolidating it anymore is using extra ELF header space. I've only looked at a few arches, but it looks like we don't use the section headers for freeing the initmem.
And then, within the different init call levels, we call the functions in the order in which they are linked into the kernel, which is driven by the Makefile.
Yes, understood. This will still work, except for one detail: you wouldn't have just one chunk of such .initcall sections (the one in vmlinux proper), but two. So before iterating the next level you have to iterate the current level twice: once the list in vmlinux, once the list in module-lump. Then go to next level, do the same. It is true then that all things in module-lump will run after vmlinux things of the same level L. If that isn't wanted you need to introduce a new level L-0.5 for the module-lump things, at voila, they are run before the vmlinux things at level L.
How much trouble would we run into if we kept the original initcall sections in vmlinux? Would the initcall sections in the module properly merge into them? Or are we already too late and the relocation records are lost?
Inside one level again the link order specifies the order, the link order of vmlinux (as specified in the Makefile) for vmlinux things, the link order when creating module-lump for those things.
Remember, we are talking about a whole boot time of the kernel to be less than a second right now, so optimizations like this are essencial to get there.
Yes, understood. I don't see why that wouldn't be possible with the lumping together anymore, under the condition that modules will contain the original initcall sections in the future.
And this bit is trivial. I already have a patch doing that on my development node. The big problem I've been running into is wrangling the complex linker script into something we can use for the secondary linking. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkpCT8IACgkQLPWxlyuTD7JnxgCfZWDmH3f8n5RSGXPbjT2LrteU vyYAnA8cV80TiBp7rMfMxmsG2gO+rxBS =xI6f -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org