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

[Marcus Brinkmann]

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.

The console server stores an abstract representation of the screen and input
queue content.

The term server already exists.  It provides /dev/tty0 to the getty/login
program and uses the hurdio backend on the NR/console node to receive user
input or send escape sequences and normal output to the console server.

> /input:
>       1               # Rendezvous point for the first input device.
>                       # One node per device may be enough, or
>                       # it might not.

If there are multiple input devices, they are either multiplexed by the
display/input client (for example if they all belong to the same focus
group), or in the case of multi-attach, all display/input clients connect to
the same NR/display node (and write to it for input).

> /output:
>       5               # Analogous rendezvous point for an output device.

Well, input and output device clients can probably connect to the same node,
as the operations are seperated in read and write operations.

> /vt/1:
>       cooked          # For term, an interface similar to a raw
>                       # serial line.
>       raw-output      # Link to the attached output device
>                       # for applications that want to do fancy
>                       # things with the console.
>       raw-input       # Similar link to the input device.
> 
> The mapping between virtual consoles and the corresponding devices is
> internal to the console server. The raw-output and raw-input link are
> certainly not essential for the first version. In fact, it might be
> better to treat them as children of the cooked console interfase, i.e.
> /vt/1 is the serial-line-like interface, and /vt/1/output is the link
> to the raw output device.

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.  In this case, I
suggest:

1/console -> for term
1/display -> r(w) to screen content
1/input   -> w(r) to input queue

There is no direct link from the console server to the input device, and it
is not internal to the console server.  Think of screen and attach/detach. 
The console server is the screen server program, and the display/input nodes
are used by display/input clients to attach to the virtual console.

This is the only way you can use the new Hurd console.  It does not do any
physical display/input by itself.
 
> As for the display interface, one simple way to arrange it may be to
> have a rectangle of a largish constant (runtime, compile time, or per
> device, constant) width, say 1024 columns, and a variable number of
> rows. Then keep track of current geometry, and the offset to the
> current top row (for scrolling), either by some ioctls, or by storing
> the information at the head of the file.
>
> Obvious disadvantage is that it wastes some memory. But one might be
> able to permute the characters of the array so that most of the unused
> columns end up in pages of their own that need no real storage.
> Arranging it to (i) not waste memory, (ii) be useful with mmap and
> file change notifications, and (iii) handle scrolling efficiently,
> both of the entire screeen and of rectangular regions, is certainly
> going to be a challenge ;-) My guess is that you'll end up inventing
> some new notification messages.

There is no need to decide on a fixed width limit.  The screen dimension can
always be retrieved with the winsize ioctl by the display client, so it can
calculate the offset of the beginning of a row by itself.  Change of screen
size is available via a signal.

The algorithm you describe is how I do it internally in the existing code.
This is very nice, but as you said, it might require a new RPC for the user
to determine the current start of the actual content, and a corresponding
"location has changed" RPC.  I am not sure if some metadata at the top of
the file is a good idea.

Have you read the three mails or so from me
Subject: improved console interface (was:...
I have this and other issues in there.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de