lkml.org 
[lkml]   [2009]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2009-08-05 18:03    [W:0.136 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site