From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755473AbYEFKUX (ORCPT ); Tue, 6 May 2008 06:20:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750707AbYEFKUI (ORCPT ); Tue, 6 May 2008 06:20:08 -0400 Received: from ns2.suse.de ([195.135.220.15]:54359 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750744AbYEFKUG (ORCPT ); Tue, 6 May 2008 06:20:06 -0400 Date: Tue, 06 May 2008 12:20:05 +0200 Message-ID: From: Takashi Iwai To: Stas Sergeev Cc: linux-kernel@vger.kernel.org Subject: Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC) In-Reply-To: <481B47DC.1010605@aknet.ru> References: <20080418014757.52fb4a4f.akpm@linux-foundation.org> <20080419021343.GA3503@nineveh.local> <20080418200237.b5a9e805.akpm@linux-foundation.org> <20080419041429.GA8508@anvil.corenet.prv> <20080418212934.bbe84ee2.akpm@linux-foundation.org> <480CD50F.20706@aknet.ru> <480E2EE5.5040208@aknet.ru> <480F95BE.60109@aknet.ru> <4811555E.3040509@aknet.ru> <48120ABF.1050802@aknet.ru> <481B47DC.1010605@aknet.ru> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 MULE XEmacs/21.5 (beta28) (fuki) (+CVS-20070806) (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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At Fri, 02 May 2008 20:57:00 +0400, Stas Sergeev wrote: > > Takashi Iwai wrote: > >> The sound subsystem is enabled (loaded) only when necessary. > >> As long as there are many systems without the sound subsystem > >> (i.e. servers), snd-pcsp wouldn't be built (thus not provided even as > >> a module) for their kernels because it prevents input-pcspkr. > > ... and I completely missed the viewpoint of device allocation. > > Yeah, that'll be a bit hackish. > I'll appreciate if your replies > became a bit less cryptic... ;) > What will be a bit hackish? [Oops, overseen this follow up] One problem is that we cannot load two drivers to a single device right now. Even if you have input pcspkr and snd-pcsp modules, you have to blacklist one of two modules so that udev loads the one properly. Because of this, snd-pcsp will be unlikely activated for most systems as default. For avoiding this, you'll have a few choices: a) implement pcspkr-core driver, and make input-pcspkr and snd-pcsp on that core module b) make snd-pcsp copmletely rely on input pcspkr, implement as an add-on by adding hook to each driver callback and event handler of pcspkr c) implement snd-pcsp as another individual platform driver and adds a hook to pcskr event handler of pcspkr The case (a) would make things more complicated and give less solution. In the case (b), the modification of pcspkr.c would be big, and would be ugly. The case (c) was my proposal. But in this case, the driver will become likely self consistent; it allocates its own device at init. In anyway, there is no sexy way to auto-load snd-pcsp (partly because it's the purpose -- avoid loading the sound subsystem unless really necessary). That's why I called it hackish. Takashi