lkml.org 
[lkml]   [2005]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c


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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.121 / U:0.892 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site