[lkml]   [2005]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c
At Tue, 20 Dec 2005 13:03:10 -0800 (PST),
Linus Torvalds wrote:
> On Tue, 20 Dec 2005, James Courtier-Dutton wrote:
> >
> > They all load in the correct order if they are modules. The problem comes when
> > one compiles them into the kernel. They then load in the wrong order and bad
> > things happen, resulting in the recommendation that alsa should always be
> > modules.
> Which, as a recommendation, is pure and utter crap.
> > In this basis, we should not have to change the code in alsa at all, but
> > instead change the kernel to understand the load order, even if compiled into
> > the kernel and not as modules.
> NO.
> The kernel does support this (and has supported for a long time).
> First off, load order matters, even in the kernel. Within one "class" of
> initializers, you can just specify the right order in the Makefile, and it
> will honor them. Of course, that ends up often being hard to do across
> different directories, which is why there's another facility:
> The kernel has several different classes of ordering. Anybody who thinks
> that "module_init()" is it, just hasn't looked at <linux/init.h>. There's
> seven different levels:
> #define core_initcall(fn) __define_initcall("1",fn)
> #define postcore_initcall(fn) __define_initcall("2",fn)
> #define arch_initcall(fn) __define_initcall("3",fn)
> #define subsys_initcall(fn) __define_initcall("4",fn)
> #define fs_initcall(fn) __define_initcall("5",fn)
> #define device_initcall(fn) __define_initcall("6",fn)
> #define late_initcall(fn) __define_initcall("7",fn)
> where the next-to-last one is the regular "device_initcall()" (and this is
> what a "module_init()" in a compiled-in driver will use).
> Now, something like the basic sound subsystem initialization should
> obviously NOT be a "device initcall". It's not a device. It's a subsystem
> that serves devices, and thus the basic sound initialization should
> probably use "subsys_initcall()" instead.
> Now, if it's built as a module, that "subsys_initcall()" ends up doing
> exactly the same thing as a plain "module_init()", and you'll never see
> any difference. But when it's built into the kernel, it means that it gets
> initialized with the other subsystems.
> Now, one thing to look out for is that if your "core sound initialization"
> depends on PCI probing having completed (ie it's not a pure subsystem with
> no dependencies on anything else), the common hack for that is to just use
> the "fs_initicall()" instead. But a truly independent subsystem (which
> sound hopefully is) should just use subsys_initcall(), and then, if that
> subsystem internally has more complex ordering, just use the link order in
> the Makefiles to indicate that.

As far as looking at the codes, it's OK for PCI. PCI is initialized
in postcore, and the only device_initcall is for pci_init(), which
calls fixup for each PCI device. This is no problem because fixup is
called in pci_enable(), too.

But for other subsystems like ISA PnP, it may be broken since some
codes are still using module_init().
(And, interestingly, fs_initcall() is rarely used in the whole fs/
codes! "grep -r fs_initcall linux/fs" hits only one file.)

So, a "safe" solution for the time being appears to be either
- to look through the whole codes and adjust *_initcall() levels,
- to force to build saa7134-alsa as a module, or
- to move saa7134-alsa.c to sound/ directory.

> > I have no idea how to get the kernel to do this though. Any pointers?
> The above should hopefully make the kernel support for this obvious.
> I thought more people knew about all this. Forcing (or even just
> encouraging) people to use loadable modules is just horrible. I personally
> run a kernel with no modules at all: it makes for a simpler bootup, and in
> some situations (embedded) it has both security and size advantages.

Yep. The driver must work both for modules and built-in. If it
doesn't work, it's called a bug, as we all know :)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-12-21 15:42    [W:0.166 / U:0.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site