Re: std location for system console

[Marcus Brinkmann]

On Mon, Sep 02, 2002 at 05:15:23PM +0200, Niels Möller wrote:
> As there have been very few concrete suggestions so far, let me
> suggest "/dev/vts/<NUMBER>/*". Some arguments:
> 
> * It hasn't got much to do with the "system console" thing, except
>   that the system console, /dev/console, may well be redirected to
>   some terminal under /dev/vts/.

Maybe system console is not a good term to use.  What I meant is just the 10
or so default virtual console you use for your 10 or so virtual terminals
which have a getty started at boot time.

Of course you can have X console servers with X * Y virtual consoles, and
all run by different users.  Then you can have Z clients attached to them
displaying their content and adding input to them.

But one console server will be the default, it will be used by the
default client which runs on the default graphic card and default PC
keyboard and PC speaker and map ALT+Fn to the nth virtual console (which
displays the nth virtual terminal, eg /dev/ttyN).  This is the setup that
people know from BSD and GNU/Linux.
 
> * "Virtual terminal" is a well established concept, and it seems to me
>   that what your server does is similar to the virtual terminals in
>   linux or bsd, only more powerful.
> 
> * The name is somewhat analogue to "/dev/pts/". That's why I suggest
>   "/dev/vts/" rather than "/dev/vt/".
> 
> I also have a question: Which processes are expected to look up these
> names, and where in the system configuration the names are expected to
> show up? getty and inittab have been mentioned already.

The one grief I have with this name is that they are, in the current
implementation, not terminals.  They are consoles.  I am not sure if
there is a hard distinction here.  But they are oriented towards the
ECMA-48 standard, not towards Unix terminals.  The terminal stuff
(and things like \n -> \r\n conversion) is mostly in the term server.

So, maybe /dev/vcs would be the name to go.

OTOH, maybe with Rolands terminal library, the console server will also
provide tty nodes.  In this case vts would fit.  For now, the ttys have to
be set up individually, one by one, with /dev/tty1 pointing to
/dev/vcs/1/console for example.

What I wrote is not really similar to virtual terminals in Linux or BSD.
It is similar to what Linux and BSD use under the hood in the virtual terminal
code.  I wrote the virtual console, that can then be used by terminal code
as a backend.  But I don't know of any system which exposes this layer in
its external interfaces.  The Linux /dev/vcs* interfaces are probably more
similar to what I did, but much, much less powerful.

The processes which look up these names are not Unix processes.  Unix
process look up the tty node (but see above, it might become integrated some
time).  The tty node looks up the NR/console node.  The console _clients_
which display the virtual console content are using NR/display, the input
drivers of these clients write the user input into NR/input.

The console server thus acts as middle layer between the tty on the one hand
(and thus the Unix application) and arbitrary display/input drivers on the
other hand.

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/