Re: Re: [RFC] alternative kernel multimedia API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Pavel Machek wrote:


One thing current interface can not do is to put driver into userspace.

And yes, we *need* userspace devices for many cams, as you will be shot
if you try to do format conversion in kernel.

Ok, you need to be able to "register" userland processes in the /dev namespace with devfs (or a similar namespace). Maybe add the capability know from the doors api, that the called process uses the callers thread to do some processing before returning. (the doors linux implementation does this quite cheap cpu wise). And possible add a bit more extensible caller parameter marshalling method than the simple arguments you pass with an ioctl; a generic xpcom interface.

If you had these three capabilities, a lot of system code could happily live outside of the kernel, but under the control of a filesystem with its native access control and ease of lookup.


--
-Torgeir





[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux