Re: X and other visions

[Marcus Brinkmann]

At Sun, 13 Jun 2004 19:43:14 +0200,
Bas Wijnen wrote:
> 
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain; us-ascii (quoted-printable)>]
> Hi,
> 
> A comments which I consider more important, which is also the reason I
> crosspost this to l4-hurd:
> 
> Suppose we have a system in a classroom, as described below.  At (local)
> login, a capability for the sound card should be given out.  At logout, this
> capability should be revoked, including all copies made of it.  This to
> prevent the user from setting up a server in the background enabling him or
> her to use the sound card remotely.
> 
> Does the capability library have a system for that?  If not, can it easily be
> implemented in the server using the lib?  I think it should be in the library,

There is a lot one can say about this, and it is all interesting and
relevant.  However, one should not lose focus.  The application you
mention is just one specific possible scenario.

First, this has almost nothing to do with capabilities.  Capabilities
are managed by the server, and he can revoke access to a capability
object on a per-task base.  This is all you need to implement such
functionality.  Either by allowing a login session manager to revoke
the access, or by revoking the access yourself if you act as a proxy
between the system and the user.  So, let's put the cap system aside.
The cap system's funcationality is very low level, and it tells us
almost nothing about the specific issues with sound and the console.

There are basically two philosophies when it comes to a sound card:
One is to think of it as an integral part of the system console.
Which is the physical devices that make up the human-computer
interface at a single place.  Other parts are one or several monitors,
keyboards, mice, touchpads, microphone, a web cam etc etc.  You seem
to think of it this way in your scenario.  In this case, you want to
control access to the sound card in the same way as with the other
devices: The device gets a dedicated use for that user's login session
for the time the user is logged into the machine at that physical
console.

In this case, the ideal scenario is sound integration into something
like KGI, which provides abstract consoles which are then
mapped/multiplexed to several groups of devices.  In this case, the
sound card could be shared among several consoles easily (for example,
X sessions at VT7 and VT8), pretty much in the same way as the kbd,
monitor and mouse are.  In this case, you don't really think about
sound cards, but more about sound output channels, and maybe input
channels (microphone for voice over IP etc).

This is all a evry legitimate and useful look at the situation.  If
this is how you want to use the soundcard, a setup like the one you
describe is natural.  And its implementation would be in the form of a
management layer like KGI which maps virtual console instances to
hardware console devices in a clever and useful, and configurable way.

Developing such a management layer is a huge task in itself, but it
would basically allow you to watch a video on one VT, and have a
telephone conference on another VT, and switch between the VTs to hear
the sound from the video or continue your phone call.  Interesting
scenario, and totally unimplemented even in GNU/Linux or BSD, as far
as I know.  Even KGI doesn't tackle sound issues at all.  And desktop
environments like Gnome or KDE rely on a sound daemon which usually
uses a dedicated sound card.

The other way to look at the sound card is that of a dedicated
hardware.  A hardware that is stand-alone and not associated with an
abstract console entity.  It is not grouped with other input/output
devices.  For example, a sound card that you use to monitor the sounds
in the room where your baby is sleeping is such a dedicated device.
You would probably _want_ to access that sound card remotely.  Or
another example: You use the sound card in a professional sound
studio.  Actually, I am a bit unimaginative here.  I am sure lots of
people can come up with clever ideas that totally break havoc with
your login session idea in certain applications.

So, what's the solution?  The trick is to stay configurable.  The
management layer would only make use of the soundcard if it is
configured to do so, and that's the main purpose of the sound card.
If the sound card is used in other ways (as sound server, whatever),
then you would not configure the management layer to use the
soundcard, and instead use it directly pretty much in the way it is
used today under GNU/Linux.  You can probably even share a single
soundcard to some extent, if you take a more abstract look at a
soundcard as a provider of many audio channels.

This field is probably as rich or richer than video cards, but mostly
unexplored.  It's certainly way outside the scope of anything we are
working on right now.  In any case, the cap system is flexible enough
to allow all this and more.  This shouldn't come as a surprise, of
course.

Thanks,
Marcus