Messages in this thread | | | Date | Thu, 06 Aug 2009 01:02:50 +0900 | From | Tejun Heo <> | 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
| |