Marcus Brinkmann <[EMAIL PROTECTED]> writes: > I don't know STREAMS, but having all these little servers stacked makes me > think of performance :)
At least this is a case where the hardware seems to evolve faster than the typing speed of the typical human... > I am more interested in learning about possible uses of this interface > rather than the implementation details. I have no examples. Naturally, most or all existing programs go through term, even when they really want to talk to some component on the other side of term. For instance, to set the baud rate of a physical serial port, one talks to term, which talks to the device which talks to the underlying hardware. Anything you ever want to do with the device, you must also support in term. But it's somewhat ugly that term should need to know about those details, it would be cleaner if you could direct the request directly to the device that is responsible for the serial port. One idea might be to add an rpc delegation/forwarding hack to libports. When the demuxer for a port receives a message it doesn't know how to handle, it can look at the forwarding attribute of the port, and if set, it passes the rpc on to that port. For instance, term could install a port to the underlying device, be that the console server or some serial port. All of this is of course a nice-to-have feature, I'm sure it can be added later if the need arises. /Niels _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
