Re: netfs part of a console server with server-client model

[Niels Möller]

Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> 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