Mailinglist Archive: opensuse-kernel (59 mails)

[Jeff Mahoney <jeffm@xxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greg KH wrote:
> On Tue, Jun 23, 2009 at 12:30:41PM -0400, Jeff Mahoney wrote:
> > Greg KH wrote:
> > > On Tue, Jun 23, 2009 at 12:17:17PM -0400, Jeff Mahoney wrote:
> > > > Greg KH wrote:
> > > > > 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.
> > > > >
> > > > > 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.  If you look at some of the recent changes that were
> > > > > made for "fastboot", we reoder the Makefiles to allow some things to run
> > > > > in parallel before others do (like ata drivers very early, before other
> > > > > drivers in the same run level to take advantage of the slowness of those
> > > > > initialization sequences).
> > > > >
> > > > > So if you just take the module init sections, and run them some time
> > > > > after all of the above sections run, then you don't get the same
> > > > > speedups that we need.
> > > > Not having that information in the module is a file size optimization,
> > > > not a real requirement. We could easily link in the initcall*.init
> > > > sections into the modules and then use them for proper ordering when we
> > > > relink the kernel. Since the initcall sections are consolidated into one
> > > >  during the original link, we would have to add a trampoline initcall to
> > > > the end of each section to call out to the linked in ones. Since they'd
> > > > be at the end of the runlevel, the ordering would be preserved.
> > > No, the main issue is the order _within_ the runlevel.  Almost every
> > > driver is in the "main" device_initcall level.  But the ordering within
> > > that level matters, and that is only definied by the Makefile order, no
> > > symbol resolution or anything else specific we can determine later.
> > I get that, but if it's safe to run it as a module later why would it
> > matter if it's run at the end of a runlevel instead of the middle of it?
>
> It is "safe", it just isn't "fast", which is one of the main goals here.

Oh ok, I see what you're getting at, but I think the order in the
runlevel really only matters if it's slow vs fast. Granularity can't be
that important. Runlevels are essentially *free* so we can do things
like slow_device_init() if we want. Depending on link order works, but
we end up with this mess now where a monolithic beast of a kernel is the
"best" option. I was pretty happy leaving the 1.2 kernel behind. :)

- -Jeff

- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkpBEGgACgkQLPWxlyuTD7II7QCgiuUfxn1rAc10R57zj8CwqwbB
o0EAnRaF+iS478ONn5g7dzelDK6YhIOz
=9Hdr
-----END PGP SIGNATURE-----
-- 
To unsubscribe, e-mail: opensuse-kernel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-kernel+help@xxxxxxxxxxxx