2015-09-16 20:06 GMT-03:00 Samuel Thibault <samuel.thiba...@gnu.org>:
> Diego Nieto Cid, le Wed 16 Sep 2015 22:12:19 +0000, a écrit :
>> Except for how to know which one the send right was obtained from in
>> the translator when a message from a client comes?
>
> term is probably easier to have a look at: see the file_set_translator
> call in hurd/term/main.c. The idea is that the translator attaches
> itself as an active translator on the other node. Since it explicitly
> create another control port, it can serve things differently there.
>
Clever idea. Indeed, it doesn't have to be the same port. I was thinking
inside the box of settrans :(
>> What comes to mind, is that a translator can serve a directory and the
nodes
>> inside it. The console does it, IIRC.
>
> Yes. Perhaps it'd be easier.
>
Another alternative, I was considering while going back home from work, is
to design this in layers. As in the following graph:
+--------------------------------+
| Applications |
+--------------------------------+
----> read, write, ioctls...whatever is
standard
+------------+ +------------+
| /dev/audio | | /dev/mixer | ...
+------------+ +------------+
----> might be some custom protocol if
required
+--------------------------------+
| driver translator |
|--------------------------------|
| rump |
+--------------------------------+
+--------------------------------+
| hardware |
+--------------------------------+
In that way there are several sound related translators separating the
concerns while the hardwarde is still accessed by a single translator
avoiding the conflicts Robert mentioned.
I hope this makes sense :)
