Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932304AbVLUOg2 (ORCPT ); Wed, 21 Dec 2005 09:36:28 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932435AbVLUOg2 (ORCPT ); Wed, 21 Dec 2005 09:36:28 -0500 Received: from mx2.suse.de ([195.135.220.15]:49297 "EHLO mx2.suse.de") by vger.kernel.org with ESMTP id S932304AbVLUOg1 (ORCPT ); Wed, 21 Dec 2005 09:36:27 -0500 Date: Wed, 21 Dec 2005 15:39:37 +0100 Message-ID: From: Takashi Iwai To: Linus Torvalds Cc: James Courtier-Dutton , Adrian Bunk , Sergey Vlasov , Ricardo Cerqueira , mchehab@brturbo.com.br, Linux Kernel Mailing List , video4linux-list@redhat.com, perex@suse.cz, alsa-devel@alsa-project.org Subject: Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c In-Reply-To: References: <20051220131810.GB6789@stusta.de> <20051220155216.GA19797@master.mivlgu.local> <20051220191412.GA4578@stusta.de> <43A86B20.1090104@superbug.co.uk> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 MULE XEmacs/21.5 (beta21) (corn) (+CVS-20050720) (i386-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4370 Lines: 95 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 . 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/