[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: std location for system console

From: Marcus Brinkmann
Subject: Re: std location for system console
Date: Mon, 2 Sep 2002 19:32:07 +0200
User-agent: Mutt/1.4i

On Mon, Sep 02, 2002 at 07:08:13PM +0200, Niels Möller wrote:
> "console" is ambiguous.
> The word "tty" or "terminal" can also mean

Cool :)  We have a bunch of words for a bunch of objects, but no good
mapping between them.  ;)

> > OTOH, maybe with Rolands terminal library, the console server will also
> > provide tty nodes.
> But for now, both the tty-node and your "console"-interface needs
> names. These almost synonymous words are annoying. Say tty-code is
> intergrated in the console server. Then you'd have both
> /dev/vts/17/console and /dev/vts/17/tty. How confusing is that?

Well, it's not perfect.  OTOH, terminals in their broadest meaning are such
a general mess anyway that we can probably never clean this up anymore.

> > 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).
> So the "system configuration" is in the passive translator settings of
> the tty nodes, right?


> It seems a little annoying and redundant to have
> a bunch of almost identical tty nodes on disk. It would be nice if one
> could just create the ttynodes on demand.

That's the idea behind Rolands term library, I think.  Also to not have
multiple processes.
> Hmm, one hack would be to have the console server provide nodes
> /dev/vts/17/tty, which have only a passive translator setting, no
> data. This will just tell libdiskfs to start corresponding term
> servers when needed. If init has a dir_notify on /dev/vts you could
> configure it to start getty on all new ttys that appear. I don't know
> how one would handle ownership of the tty nodes, though, perhaps one
> should look at /dev/pts and do something similar.

I don't think that works?  Whose libdiskfs do you mean here, probably ext2fs
if the filesystem the /dev/vts resides on.  But that filesystem does not
play in the game anymore when /dev/vts/NR is resolved, this is done by the
console server.  The console server does use libnetfs, not libdiskfs, but I
could probably get it to automatically start a term process anymore.
So if you mean that the console starts a term server, that could work.

There is only a small glitch, but I guess we have this anyway.  term must
know about its path, and the path to the console.  Well, when term is fully
integrated, it doesn't need the path to the console anymore, but it will
always need the name of itself.  So, by transfer, the console server needs
to know its path, and we need to pass it the path on the command line.  I
guess that is ok (although I would make it optional if you don't want the
tty nodes).

The only other drawback I see is that it makes virtual consoles stay around
as long as this tty process is running, which means forever.  The current
code exploits that term hangs up when the last user goes away, and then the
virtual console is destroyed.  With a fixed set of ttys/vts/whatever used
and installed by /etc/ttys this is no issue at all anyway, but maybe we will
get more creative with consoles and virtual terminals later on.


`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]