Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Takashi Iwai <tiwai@suse.de>]

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 :)


Takashi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/