Marcus Brinkmann <[EMAIL PROTECTED]> 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?
> What I attach to this mail is a file that incorporates some the virtual
> console abstraction in console/console.c in the Hurd source tree, and new
> parts which provide a netfs based filesystem that looks like this:
>
> console:
> drwxrwx--- 2 root root 0 2. Jun 04:27 1/
> drwxrwx--- 2 root root 0 2. Jun 04:27 3/
> drwxrwx--- 2 root root 0 2. Jun 04:27 4/
I'm a little confused by the fact that you use the same id:s for both
the "consoles" and the "displays". I would have expected something like
/:
vt/
input/
output/
/input:
1 # Rendezvous point for the first input device.
# One node per device may be enough, or
# it might not.
/output:
5 # Analogous rendezvous point for an output device.
/vt:
1/
2/
4/
/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.
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.
/Niels
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
