Re: std location for system console

[Roland McGrath]

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

Well, I am not sure we have ever specified it.  It could be for things that
are miscellaneous RPC services, while /dev is for things opened for io in
the normal way.  It could also be system-wide unique things as opposed to
instances of things of which there could be many.  There is one
/dev/console, but I don't think the "console" in the sense of what
/hurd/console provides should really be thought of as one system-wide
service.  It's a device of which there could be many, e.g. a single system
with multiple video+keyboard+mouse sets would naturally have one "console"
for each.  Or generalize that to multiple "UI outlets" meaning video+kbd or
serial port or purely virtual things (e.g. vnc) or a USB-attached monkey
brain, or whatever.  

I don't think it makes sense to have a canonical _SERVERS_* path for
something of which there could be arbitrarily many and a user in fact will
want to connect to an arbitrary particular one.  For user convenience it
can default to some standard name, but that is just like a terminal
emulator defaulting to /dev/modem--i.e. convention for convenience,
not canonical system protocol.

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

I don't care what the names are.  Using subdirs seems cleaner, the only
reason I can think of to want ttyN is if there are misc. programs assuming it.

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

Why do you need anything special?  The getty on tty1 will start the console
server via passive translator if need be, so the backend is always there
when you need it.  Running the console-console client on the console can be
started whenever, as long as it's before X or whatever else it might need
to negotiate with for hardware access.  Whenever console-console starts it
can fetch the hardware screen contents and stuff them into the tty1
scrollback buffer.  If the console server's tty1 state keeps track of a
"screen cleared since startup" flag, then it can dtrt whether it should
display old contents scrolled to show getty output or a cleared screen with
getty output at the top and old contents saved whereever scrollback gets
saved when you clear the screen.  i.e., either way it just inserts the old
contents into the tty1 software state as "what was there before writing
started".  The only thing hard to support is having old contents, then not
clearing the screen but moving the cursor around and partially overwriting.
But I really don't think we should care about that. 

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

Yeah, good point.  The oskit-mach console is pretty close to no console at all.
We just need whatever the fallback is to be very simple and robust so that
you cannot manage to misconfigure it and be unable to boot singleuser to deal.