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]

Date:	Wed, 5 Aug 2009 15:29:42 +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

> > 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.
> 
> The sharing and mixing and matching can happen very gracefully at
> chrdev level.  Does it make sense to drag it down to each subsystem
> level just to use custom module alises?  Not at all to me.  The same
> goes for video or whatever.  There is no reason to claim unused device
> numbers anymore and as long as that holds everyone is good citizen at
> the chrdev region.  That's _much_ cleaner.

I would suggest you read the code for the others. OSS is probably the
easy one to kill but the others create objects for platform wide sysfs
files and the like (as indeed OSS once did for a proc file) so in the
general case CUSE needs to work through them.

>  * OSS compatibility as seen from userland apps : relevant
> 
>  * doing everything right by sound_core.c which basically is only used
>    by in-kernel emulation : not so much

So instead of weird config magic why not send both messages. Initially
soundcore can generate both requests for sound-slot-foo and also fake up
its own char requests. It's easy to do, it doesn't put any code into the
kernel we'll be stuck with for years with weird config options. It
doesn't require the user choose a magic kernel option - it just works.

It's not much code either - just another request call in soundcore_open -
one line extra to write, a year to wait (4 releases ?) and then the old
stuff can go away, ALSA can then avoid soundcore and soundcore can vanish.

Much cleaner, and I believe one line of code ?
--
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/