Re: console plans

[Roland McGrath]

> > You can add this to the hurdio bottom half now and test it with term
> > stacked on term: when it gets SIGWINCH, do TIOCGWINSZ on the underlying
> > term and propagate the change up
>                ^^^^^^^^^^
> Should this be TIOCSWINSZ?

No.  SIGWINCH tells you that the size has changed and so you need to use
TIOCGWINSZ to find out what it is.  So, when the console changes its size
(if it ever did), then it would trigger a SIGWINCH that the term hurdio
backend would get and know to do TIOCGWINSZ and then propagate the change
up by producing a SIGWINCH to its clients.

> I am unsure about this.  Let's start with initialization.  Currently, the
> console can report back the size of the screen with TIOCGWINSZ, while
> TIOCSWINSZ is ignored (changing the size of the screen is simply not
> supported right now).  However, nothing ever calls TIOCGWINSZ on the console
> node.  It seems to me that it is terms responsibility to call TIOCGWINSZ on
> the underlying node at initialization.  

That is exactly the extension to the hurdio backend that I described in the
first place.

> [...] So maybe this is how it should be initialized?

Yes.

> Ok.  What about the client?  Will that be started by console-run, or later?

Later.  We should have some sort of special case that's used for the
singleuser shell or something.  But in the normal case, you'd want it to be
later, part of the whole runsystem world with arbitrary amounts of local
configuration.  The default configuration would use a standard VGA client,
but deciding that might at some point be part of some more general hardware
detection stuff or driven by multiboot info that says what input and output
devices should be the console.  The configuration for headless
installations might have just a VNC or other network-accessible console
client (supdup!), or no default clients at all.

For the failsafe cases and early boot messages, there are a few ways to go.
The earliest boot messages are already sent via the Mach "console" device
directly, but that is just the essential servers before console-run.  For
anything else, I think whatever the hackery is belongs in console-run
and/or in the console server itself.  One idea is to have a feature of the
console server where it has a special built-in byte-snooping client
(i.e. getting the byte stream before the terminal emulation code) that uses
the Mach "console" device with just CRLF translation; this built-in client
would automagically disable itself when the first real client attached.
That way, the output would go to the screen via the trivial console device
for any printfs or emergency shells (keyboard input too in that case) until
the fancy console got going.

But now I have what I think is a better idea than that one.  It's more
robust to leave the console server out of it--much less pressure to be sure
it never ever crashes.  The obvious way to do that is to use just term (as
we do now in the absence of a console server).  The bootstrap stuff and
console-run can stay just as they are now.  Furthermore, the /dev/console
translator setting can stay as it is--using the Mach device backend.  All
we have to do is make term support switching backends on the fly.  The code
in runsystem or sysvinit or whatever can start up all the consoles it sees
fit and decide they work, then do fsysopts /dev/console hurdio /dev/tty1.
We might use that same facility to implement console-redirection as Linux
et al do with TIOCCONS.

The advantage of having the console server do it is that the switching can
be visually seamless because the display's matrix contains the stuff that
was printed before the console client started and so in the usual case it
will take over and redraw the screen with the same contents.  With the term
backend-switching plan, nothing printed before the fancy console got going
will be on the screen any more.  But you have that issue with anything
printed by the kernel or boot loader or init anyway.  For visually seamless
switching perhaps the thing to do is give the VGA client an option to read
the state of the VGA hardware when it starts and fill that into the display.