[Top][All Lists]

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

Re: std location for system console

From: Niels Möller
Subject: Re: std location for system console
Date: 02 Sep 2002 22:02:02 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:

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

> I don't think that works?  Whose libdiskfs do you mean here, probably ext2fs
> if the filesystem the /dev/vts resides on.

Sorry, I meant the libwhateverfs that is linked into the console
server process.

> The console server does use libnetfs, not libdiskfs, but I
> could probably get it to automatically start a term process anymore.

The idea was to return "this node is a translator" to the fs-library,
which will then start the translator and return its port to the
caller. Or if that doesn't work, the console code could start term

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

If term is started by console, the console needs to know the path to
the term binary. But I think that's all anyone needs to know, it can
give term a port to the /dev/vts/17 directory, and term can do a local
lookup of "tty" and "console" there. Or a port directly to
/dev/vts/17/console. Perhaps it doesn't work with the standard
translator startup messages, but I don't think it should be too hard
to arrange.

> 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, [...]

Is there any problem with having the tty process (with that, you mean
the term program running as an active translator, right?) exit when the
last user goes away? The tty node, /dev/vts/17/tty, will still be
there until the entire console 17 goes away, with the same passive
translator setting.

Alternatively, the term process could close its console port
/dev/vts/17/console, but stay attached to the /dev/cts/17/tty node. If
the console server decides this virtual console should be destroyed,
it can tell the term process to go away, or simply orphan it if it


reply via email to

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