[Top][All Lists]

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

Re: std location for system console

From: Thomas Bushnell, BSG
Subject: Re: std location for system console
Date: 01 Sep 2002 22:00:42 -0700
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

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

> > Unlike Roland, I dislike subdirectories in /dev, but
> > it's not really a very big deal.
> > 
> > Remind me why these are somename/NUMBER/console and not just
> > somename/NUMBER?
> Sometimes I wonder where you have been when all this has been discussed. ;)

Oh, sitting on my hands. :)

> The console server provides three access nodes for each virtual console it
> provides:  "console" for term, "display" for clients to get the screen
> matrix and its changes, and "input" for clients to add input to the virtual
> console.
> It simply makes a lot of sense to bundle all those nodes into a single
> directory NUMBER rather than having console/NUMBER, display/NUMBER etc.  One
> reason is that it better reflects the hierarchical structure.  Another is
> that you can request dir notifications from someplace/ to be informed about
> new virtual consoles, a third one is that it is easier to lookup the parts
> of a console (first you get a port to the NUMBER directory, and then you
> lookup display and input).

Ok, like I said, then, I don't have any particular advice about the
specific names.  I agree that the better hierarchical structure (if
you have to have directories) is {1,2,3,...}/{console,display,input}
rather than {console,display,input}/{1,2,3,...}.  And since you can
have the directory translated by the program, then that makes it
pretty elegant.

There is an ambiguity here about what "/dev/console" should mean,

Either /dev/console is a redirectable hardware device, and the fancy
console driver runs on it, or something *else* is the hardware device,
the fancy console driver runs on that, and then /dev/console points at
one of the fancy console driver files.

I prefer the *latter* solution, by far.

reply via email to

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