[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.030 / U:30.944 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site