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 _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd
