> In summary, while we created an `automatic' /dev/console, we lost the ability
> to access the current virtual console (formerly /dev/tty0), or am I missing
> something??
When I wrote the change, my thought was that /dev/console would
continue to work as before (it already was automatic) when there are
the virtual terminal devices. However, I failed to bring this thought
into the code.
The concept of console is a bit vague here and in the source. In my
view console is the device for managing the machine and where kernel
messages go and from which you can get the single user shell
prompt. Video and keyboard and the virtual terminal devices using them
are just one fancy device driver among the serial ports and other
terminal devices. Their only association with console is that they
could be used as a console, just like most other terminal
devices. /dev/console should not be relied for giving any virtual
terminal. It can be relied to find the console.
This is simple logic (albeit new with the introduction of alternate
console devices): if it is true that
virtual terminal is a console
it does NOT follow that
console is a virtual terminal
Now, when we have no /dev/tty[1-9]* devices, I thought that best is to
have /dev/console go automatically to any existing console device. The
c 4 0 is pairs nicely with c 5 0, which is the tty of the current
process, so I thought I keep using that.
The only problem that I see is that programs rely on the old notion of
console to find foreground virtual terminals. This can be alleviated
by giving /dev/tty[1-9]* priority over serial consoles, so that they
are /dev/console when both vt and serial consoles are used. Some
people might not want that, but they are minority and still not worse
off than before the serial console change.
----- Marko Kohtala - Marko.Kohtala@ntc.nokia.com, Marko.Kohtala@hut.fi