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

[Linus Torvalds]

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.

> 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.

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