linux-kernel - Re: [PATCH 2/2] sound: make OSS device number claiming optional

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: <20090805112649.4a59ce70@lxorguk.ukuu.org.uk>
Date:	Wed, 5 Aug 2009 11:26:49 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Takashi Iwai <tiwai@...e.de>
Cc:	Colin Guthrie <cguthrie@...driva.org>, Tejun Heo <teheo@...e.de>,
	Greg KH <greg@...ah.com>, Al Viro <viro@....linux.org.uk>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] sound: make OSS device number claiming optional

> As far as I understand, the current problem is that ALSA core becomes
> dependent when you build with CONFIG_SND_*_OSS config, even if you
> load no snd-*-oss modules and use only ALSA-native ones.  It's because
> the OSS device registration is done through the ALSA snd module.
> Thus, loading ALSA modules always results in loading soundcore
> module, too.

That isn't a bug, but a feature.

> So... instead of hacking around soundcore stuff, splitting off the OSS
> (soundcore) dependency from ALSA snd module could be another solution?
> Then soundcore doesn't have to be loaded unless you load snd-*-oss or
> any real OSS modules.

This makes it worse.

> One drawback is that this splits to yet another module.  Or, maybe it
> can be put into somewhere else...

Currently I can load bits of OSS driver, ALSA drivers and something else
at the same time and soundcore will properly share the major number
between devices and do allocations (Just as miscdevice does with its
major).

If people start hacking around the interface rather than using it
properly then the end user is left with

- obscure magical configuration Kconfig items
- a weird boot parameter/module option
- no ability to mix and match

Exactly why is that a forward step compared with teaching CUSE to behave
like a civilised kernel driver with regard to sound ?

If CUSE/Sound is fixed to use the sound APIs then lo and behold

- no weird options
- no weird boot parameters
- mix and match just works

no user intervention, no complexity to the end user, and more flexible
all around.

(Its also better for debug as you can load two different versions of the
CUSE/Sound stack at once ...)

Hence I still think this patch is an ugly pointless hack that is nothing
but private debug and quick hack stuff. Teach CUSE to behave and
everything works nicely. CUSE needs this sort of additional plug in
support anyway in order to do anything with it involving the other
multiplexed device interfaces (eg tty, video4linux, framebuffer, usb, ...)

--
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/