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] [day] [month] [year] [list]

Message-ID: <48208C85.30606@aknet.ru>
Date:	Tue, 06 May 2008 20:51:17 +0400
From:	Stas Sergeev <stsp@...et.ru>
To:	Takashi Iwai <tiwai@...e.de>
CC:	linux-kernel@...r.kernel.org
Subject: Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)

Hello.

Takashi Iwai wrote:
> 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.
I thought all (or most) alsa drivers
are allocating device on init, even
though this is explicitly discouraged
in the docs. So I was considering this
as a possible solution with the minimal
drawback.
But... as long as the autoloading by
default is not needed, and both drivers
can be at least built together, and not
too much distros have pcspkr built-in,
I thought the current solution - having
pcspkr as the default but to let the user
to choose snd-pcsp, is not all that bad
too. I guess it costs only adding a single
alias into modprobe.conf to choose snd-pcsp.
And I also think _most_ distros do not
mind having the sound subsystem loaded
by default, but some certainly do. For
those that do, the user will have to add
an alias. For others - he may get snd-pcsp
right away. IMHO this is rather acceptable.
--
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/