Mailinglist Archive: opensuse-kernel (59 mails)

< Previous Next >
Re: [opensuse-kernel] Moblin kernel merged to FACTORY
  • From: Jeff Mahoney <jeffm@xxxxxxxx>
  • Date: Tue, 23 Jun 2009 22:04:37 -0400
  • Message-id: <4A4189B5.7040304@xxxxxxxx>
Hash: SHA1

Tejun Heo wrote:

Jeff Mahoney wrote:
Tejun Heo wrote:
Recent kernels produce modules.order which lists the makefile order of
modules and is currently used by modprobe to determine which module to
load when multiple modules match a device alias. It can take some
work but I don't think it'll be too hard to make the fast loaded
modules to observe link order.
Now this would be really interesting. I was concerned about having
multiple .init sections and started doing some work in that area, but I
do like the idea of generating the link order via that mechanism instead
of just guessing using modprobe.

Have you played around with this at all yet? I realized this morning
that my linking attempts were actually done on the compressed image, not
with the real vmlinux. The differences are huge: checkout
arch/x86/kernel/ - I'm not sure how to reliably generate a
good replacement since it folds sections, etc.

Nope, not yet. I think there can be two different approaches here.

1. Try to create a `static' image from vmlinux and target modules. I
doubt this would work very well. There are subtle module specific
things which are setup by the module load code and I don't think
this will be too easy.

Like what? AFAIK the only difference between a built-in.o and a
<module>.ko is that the module has the <module>.mod.o added in which
only contains a few sections. The conflicting sections can be renamed or
dropped with objcopy before actually linking the static image.

I had planned on ignoring the fact that it was a module and adding the
static .initcall.init section to each module just like what would happen
if it were compiled as a static object. That way, we can just link it in
and the initcalls will be in the right section. Since it becomes
statically linked, there's no need for the module loading code to be
invoked. That's where the fun in ordering comes in, especially because
there aren't separate initcall sections in vmlinux.

2. Create an very early initrd thingie which gets loaded by the boot
loader and gets unpacked and loaded early during boot. This should
be easier but I'm curious how much difference it would make
compared to normal initrd if we can make it go faster

Maybe it would be better to think about how to make initrd go faster.
If the dynamic relocation time is problem, we can reserve an area in
the FIXMAP area and pre-relocate modules and make them a bundle and
suck it up into the kernel at once and run initialization for them as
usual. It'll be slower than monolithic kernel but hopefullly not by
too much.

This runs into the same problem Greg keeps underscoring. The issue is
that we want to initialize some things earlier in the boot cycle. In
reality, there aren't many of them right now where this will happen -
but it's possible to add more runlevels to allow finer granularity when
defining the module init.

- -Jeff

- --
Jeff Mahoney
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE -

To unsubscribe, e-mail: opensuse-kernel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-kernel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups