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


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