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: <4A79AD2A.4060308@suse.de>
Date:	Thu, 06 Aug 2009 01:02:50 +0900
From:	Tejun Heo <teheo@...e.de>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
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

Hello, Alan.

Alan Cox wrote:
> 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.

I don't think it's wise for CUSE to try to emulate all those.  CUSE
provides emulation for a character device file and that's it.  It's a
building block not a complete solution.  In many cases information
provided via sysfs or proc doesn't matter to much for individual apps
and there's no reason to try to emulate them.  For other cases, those
nodes would need to be emulated using other building blocks - tmpfs or
fuse overlay mount maybe.

>>  * 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.

It's weird but simple and the alternative behavior of only acquiring
existent devices shouldn't hurt anyone who's using anything remotely
modern.  The only thing that changes is the module alias kernel
requests after all.  Oh well...

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

Hmm... the problem is that the old stuff claims the whole chrdev
region.  I was thinking about adding support for alternative module
alises at the chrdev layer if this is that essential and changing
sound_core to claim only the devices which actually exist.  That way
we can continue to use the same module aliases and allo OSS emulation
and ossp to occupy the same kernel.

I don't see how I would be able to achieve the latter with one liner.
Can you please elaborate a little bit?

Thanks.

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