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

[Niels Möller]

Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:

> On Sun, Jun 02, 2002 at 03:00:15PM +0200, Niels Möller wrote:
> > Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
> > 
> > > VISUAL DISPLAY I  \                     /
> > > VISUAL DISPLAY II  |                   | TERM ON VIRTUAl CONSOLE I
> > > ...                 >  CONSOLE SERVER <  TERM ON VIRTUAL CONSOLE II
> > > INPUT DEVICE I     |                   | ...
> > > INPUT DEVICE II    |                   |
> > > ...               /                     \
> > 
> > I take it the entries of the left hand side correspond to real
> > devices?
> 
> No, they are all programs (Hurd servers or clients).
> 
> The visual display/input device client(s) handle the actual presentation of
> the screen matrix to the user and feed the user input to the console server.
> This is like the VNC client for example.

So if you have N virtual terminals, then you also have N instances of
"display" and N instances of the "input". That makes it clearer.

But what about the actual multiplexing of N virtual terminals onto 1
screen and keyboard? I thought that was also part of the console
server, but now it seems that has to be a separate program. Which
makes some sense, I just don't remember that being mentioned before.

> I am not sure what you have in mind.  Maybe it is useful to provide raw
> write access to the text matrix in the console server.

That's a nice-to-have thing. Consider an alternative curses backend
that doesn' use the old fashined escape sequences. There may be other
interesting uses (like, display hacks), but I guess it's not terribly
important.

> In this case, I
> suggest:
> 
> 1/console -> for term
> 1/display -> r(w) to screen content
> 1/input   -> w(r) to input queue

The only point of having display and input be children to the console
node is that if I'm given only a port to the console (say, it's my
process' stdin), I can easily get to the raw display with a single
dir_lookup on that port. But one could of course use some other rpc
for that, if needed.

> There is no need to decide on a fixed width limit.

You're right. I have forgotten much of the previous discussion, but
now I think that the conclusion was that resize will be somewhat
expensive, but that's no big problem because it doesn't happen very
often.

Regards,
/Niels