Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)

[Takashi Iwai <tiwai@suse.de>]

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