Re: std location for system console

[Marcus Brinkmann]

On Fri, Aug 30, 2002 at 09:51:18PM -0400, Roland McGrath wrote:
> > is that ok with you wrt integration of the console into the existing system:
> 
> Let's not solidify this yet.

It has time, but I wanted to start it early, as I might need to use
something in the brltty port, which probably will not use libcons (they have
a polling model only, and for that libcons is way too complex).
 
> > /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.

Well, /dev/console is taken so you have to be more precise :P
Someting like /dev/syscon maybe.  What is the criteria for /dev vs /servers? 
As far as I see it /servers has more or less unique system wide services,
while /dev/ has Unix legacy device files.  A system console server seems
reasonably unique and non-Unix that it can be put in /servers, but I am not
married to that idea.
 
> 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.

Oh, I see.  Well, I don't see a serious problem with providing
console/NR/tty nodes.  And suddenly /dev/ is a much better place again, esp
considering /etc/ttys.  Or did you think of the console server providing
/dev/ttyNR?

> 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.

Ok.  The stand alone term server is certainly not going away, nor the
console/NR/console node which provides raw access to the console, so the
current model is guaranteed to stay around for a long time I think.

> > 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.

So you want to run it as a daemon.  How abot this:  There is a -D option
that starts the console as a daemon, so that it returns early.  There is
also an option to save the current screen content on vc 1 (or whatever), and
this is done before daemonizing and returning in the parent.  I think this
is the only sane way to guarantee that nobody writes to the hardware console.
Naturally, this needs to be done before a getty on tty1 is started.

> Single-user should probably not have it at all, so you can have fonts on
> the disk you are fsck'ing, etc.

Depends.  With a console like mach there is no problem.  With
a console like oskit-mach, it won't help relatively new users to be stuck
without visual editor and cursor keys.  With a system like L4, there
probably is no console at all.  We can think about this later.  Note that it
should be easy to provide a fallback console.  The VGA driver reads out
the font stored on the VGA card and can use that as fallback.  Other drivers
probably should have a rescue font compiled in anyway, that can display 7bit
ascii.  But I guess all these details will change several times depending on
what is more robust and available in any given configuration.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/