linux-kernel - Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <s5hr6cfd99m.wl%tiwai@suse.de>
Date:	Tue, 06 May 2008 12:20:05 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Stas Sergeev <stsp@...et.ru>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/