PulseAudio

[David Zeuthen]

On Wed, 2007-02-28 at 07:28 +0100, Nicolas Mailhot wrote:
> It's a bit more complex than that, a tuner won't record more than one
> channel at a time, so you need something between the hardware and the
> GUI frontends to warn some other user already booked a timespan. You
> know, like cups managing one system access to its printers (shock!
> system-wide-daemon for desktop use)

First I was going to say that 1) v4l devices are exclusive-openers; and
2) use O_EXCL for other kinds of devices. But then I realized you're
talking about a PVR getting ready to capture a recording in the future.

So, sure, you could have some system-wide mechanism for obtaining
exclusive access to the hardware that, in the process, would use
revoke() to kick out other openers already hogging the device. That's
something I've been wanting to put in HAL anyway (since HAL is just a
mechanism); it's probably the right place since ACL is managing your
permissions. 

Then your conceived[1] example of a PVR appliance would just work; it
would

 - You're capturing video in your login session (uid=500) - you're tuned
   into channel 825

 - Time passes

 - PVR appliance decides it wants to record BSG for you. Bummer, that's
   on channel 62 and, rats, someone is hogging the device files

 - PVR user (uid=501) calls into system-wide mechanism to get exclusive
   access on /dev/video0 and /dev/dsp

 - System-wide mechanism removes ACL's on /dev/video0, /dev/dsp for uid
   500 (it keeps ACL's for uid 501 because that's what the caller of
   of GetExclusiveAccess() has)

 - System-wide mechanism revoke()'s access to /dev/foo, /dev/bar for uid
   500. Your TV capture app in the session hopefully doesn't crash
   because access is revoked. Today it probably would :-)

 - System-wide mechanism returns to PVR user in response to the
   GetExclusiveAccess() call.

 - PVR appliance now have exclusive access, opens the devices and
   records your show

 - Time passes. Disks are spinning.

 - PVR appliance is done recording. It calls into
   ReleaseExclusiveAccess() and the system-wide mechanism reconfigures
   the ACL's. uid 500 can now access the devices again. 

 - Perhaps the video capture thing in the session for uid=500 starts
   showing something again.

Perhaps the kernel should have an option to open(2), say, heh,
O_EXCL_AND_KICK_OTHER_OPENERES that does this but all this involves a
policy decision (is uid 501 really privileged to do such a powerful
operation? The kernel just don't know...) and ACL management.  

I'll think a bit more about this; we need to get the interface right..
anyway, thanks for bringing this to my attention.

[1] : actually I bet the example is not so conceived

> Also with DVI and friends the video part may depend on a dedicated card
> but the audio just use one audio input of the motherboard/audio card.

That's just device access again - I hope with Keith's and others work on
that the kernel will, in the future, finally export device files (for
GPU's, CRTC's and monitors [2]) so we can manage permissions on them
like any other device. Then, you know, we can also run the X server as
an unprivileged process. Wouldn't that be something? :-)

Lesson here is that multi-user is *hard*. Doesn't mean it's not fixable.
It does require that apps adapt and use new infrastructure to learn
about the environment in which they're running. That's not different
from Windows or Mac OS X - many apps there don't work properly with
multi-user simply because the app developer didn't write his app with
this in mind.

     David

[2] : Hope I got that right