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

> The only problem here is the now obsolete hackish way OSS module
> auto-loading is handled.  CUSE is being a regular chardev citizen.

"obsolete hackish". It's the same mechanism used by just about every
other driver that multiplexes. Doesn't seem obsolete to me. You are
expected to register subdrivers of most specialist interfaces through
that interface. You use misc_register, video_register_device etc.

Providing you do so it all works nicely.

The OSS device major is owned by OSS (soundcore). If you want to use it
your driver should use the interfaces provided by soundcore. Ditto any
other similar interface.

If you want to completely pre-empt soundcore then use a different
(probably dynamic) major number and tweak your udev rules to create
different /dev files.

None of this requires ugly kernel hacks and weird user config options and
module params.

> Given the situation, I sure can add hacks to CUSE so that it doesn't
> do regular chardev thing but does OSS specific stuff if OSS major is
> detected.  To me, this would be much painful exercise in spreading the
> hack.

And it can then be a good citizen and share the resource. CUSE needs to
do the same for video/misc/framebuffer/tty/usb/etc so this is a general
pattern it needs to handle. In short cuse needs to grow this ability
anyway if it wants to be support these sorts of device.

> However, in-kernel OSS is largely dead or at least is dying a slow
> death.  Native OSS drivers are no longer in development and the only
> left user is in-kernel emulation from ALSA, which I'm sure have its
> places but is getting more and more inadequate for general desktop
> usage due to lack of software multiplexing.

The desktop uses pulseaudio for the most part (or jack in some setups).
OSS uses are pretty rare now that flash has gone away. Unfortunately
many of those existing users aren't terribly fixable

> I don't see much reason to go through feature removal process for the
> now obsolete OSS-specific module requesting feature.  Allowing distros
> to make the switch as they see fit and letting the code wither away is
> the least painful way.

You appear to be self contradictory here. Either

- OSS is irrelevant in which case we don't need the CUSE stuff either
- OSS is relevant in which case we shouldn't break it

A few old old games still use OSS, are proprietary apps and have never
been re-released. Some of them also do irritiating to emulate things like
use mmap. Flash at least appears to have finally gotten the message.

Alan

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