Re: std location for system console

[Roland McGrath]

> is that ok with you wrt integration of the console into the existing system:

Let's not solidify this yet.

> /servers/console is a translator "/hurd/console --encoding ISO8859-1" or
> whatever system default encoding is desired, <hurd/paths.h> gets an entry
> #define _SERVERS_CONSOLE _SERVERS "console"
> and /dev/tty2 ... /dev/ttyN are translators
> /hurd term /dev/ttyN hurdio /server/console/N/console

I dunno, /dev seems like it is more appropriate than /servers.

Also, we might not want to let this mode of separate term last for too
long.  I started a few weeks back, but never got around to finishing, a
libtermserver taking the guts out of term (and a netfs filesystem using
this to implement /dev/pts automagic ptys with all the ptys in one translator).
I think it makes most sense for console to use this model too.

Of course, we can keep supporting the current model too and it might be
handy for code isolation when debugging or developing console.  But I don't
think we want to have a canonical installation plan based on that.

> and /dev/tty1 is a link to /dev/tty, or something like that, and /dev/tty
> gets redirected to hurdio /server/console/1/console as part of the startup.

You mean /dev/console of course.  No, I think these remain separate.  If
you used a pure serial console (which can be a choice made at boot time),
then /dev/tty1 should still be the first virtual console on the VGA
console.  In that case /dev/console would be redirected to /dev/ttyS0 or
whatever.  (Or you might want a separate console server on which you have a
different set of virtual consoles accessed by having console-ncurses run on
/dev/ttyS0 at boot.)

I think what we want, rather than just using fsysopts, is a private
protocol that maps to the TIOCCONS semantics.  That is, a way some process
could open /dev/console, hand it a port to some terminal, and say "do
hurdio on that until it dies, then go back to what you were doing".  That
is how TIOCCONS works for normal programs like xterm or xconsole.  It could
be the same for a translator like console to give the /dev/console term a
port to itself.

> I can write code that makes the console-console (still for lack of a better
> name) read out the current screen content and write it back to the first
> virtual console.

Peachy.  This makes it very UI-painless to have the minimal kernel console
in force until normal multiuser startup.  I think the fancy console should
be started up in a very normal way by init (i.e. rc or inittab or whatever
it is), no different than a boot-time console X server would be.
Single-user should probably not have it at all, so you can have fonts on
the disk you are fsck'ing, etc.