Re: console-client close to initial check in

[Roland McGrath]

Fabulous work!

> For this, I plan to add a new directory
> 
> console-client/

Ok.  

> I also want to add the "vcs" target to MAKEDEV and change the tty[0-9]
> targets in MAKEDEV to point to /dev/vcs/NR/console as discussed before
> (we don't need to set it into stone, eg defining it in a header file or
> such, but having it in MAKEDEV is convenient).

I'm not sure exactly what this looked like and whether it should stay that
way.  But adding something now that works with the code you have is fine.
Anyone using this must know the console is very experimental code and we
might change it later so they'd have to fix their translator settings.

> I believe that the tty[0-9][0-9a-f] and tty[0-9a-f] as they are defined
> right now, as Mach devices, have never been used and can be safely
> removed.

Agreed.  AFAIK nothing but /dev/console has ever worked for the Mach console.

> It also makes sense to change the default ttys then so gettys are started
> on the new consoles.  But that can be done later as well, after we have more
> experience with this.  

Yes, let's wait.  I think really the best solution is not the BSD or
sysvinit style of explicitly listing many getty's, but having some way that
the console server can arrange to start them on demand when a previously
unused virtual console is switched to.  It doesn't seem especially elegant,
but it ought to be adequate to ahve a simple feature where the console
server just runs a specified shell command to do something interesting the
first time you switch to a virtual console.  I can imagine this being handy
for running dedicated things other than getty on virtual consoles, e.g. a
configuration where you bind some key to start a new virtual console
running ssh to some host or the like, or a console game or whatever other
console application you might want to let someone run easily from the
terminal without logging in.

> BTW, is there a way to get a getty on it even after boot?  

What do you mean?  kill -1 1 should make runttys reread ttys.  (Really just
SIGHUP to runttys, but signals are supposed to propagate from init to
runsystem to runttys so you can just use PID 1 as is the BSD convention.

> The problem with running just a shell on term is that the control
> characters are not properly handled (^C, ^Z etc).

I'm not sure what you are referring to specifically.  Probably just running
something without appropriate stty state and controlling tty attachment
beforehand or without a TERM environment variable.  Fixing those things for
you is pretty much what getty is for.  We should make our getty not quite
so totally stupid so you can tell it to run something other than login.
With the getty-on-demand plan above, you would want it to run login so it
times out.  In short, our getty is way way way too minimal as it is.

But it seems to me that the handy thing would be a trivial program that
does the essential tty frobnications of getty, but has none of the
/etc/ttys checks or the hard-wired crapola.  That is, it just does the
revoke+open+login_tty and then execs its arguments.  That makes it much
easier to do trivial things like run a shell or construct other things with
simple scripts.

> Please let me know if you don't want me to commit anything right now.

This all sounds great, go ahead if you think it's ready.  But this means
you are obliged to keep full ChangeLog entries for that code now, which
noone cared if you did before.

> PS: Running aafire on the client and scrolling up a couple of lines with
>     LeftAlt + ArrowUp, while the top of aafire's output keeps running in
>     the bottom half of the screen, is quite a neat effect if you are used to
>     the jumpy Linux console which doesn't like output while being scrolled
>     back.

I prefer the docile behavior too.  But it should be a user option (as it is
in xterm).  In fact, two options: jump down on new output, and jump down on
typing.