Darren J Moffat wrote:
> Riny Qian wrote:
>> Darren J Moffat wrote:
>>> On the project page there is the following bullet:
>>> "* /dev/console serves as the current active console, that is, any
>>> output via /dev/console will go to current active console."
>>> I don't think that is necessarily the correct behaviour. It also
>>> isn't the behaviour (best I can tell) that Linux has for this
>> Here we have an assumption that it is on the "workstation console". In
>> such case, /dev/console serves as the current active virtual console.
>> We won't change the basic rule that "the file /dev/console refers to the
>> system console device". For example, in tipline case, /dev/console
>> will go to serial console.
> I don't think I like the implication of this.
> Lets consider this case.
> Some part of the system starts writting messages to /dev/console, while
> it is doing that I switch to another virtual console (lets call them VTs
> for now since that is what people are famililary with). What happens to
> the output ? If I understand what you are saying it starts getting
> written on the VT I've just switch to. This is not very nice in my
> opinion and it also is not how it works on Linux.
> Best I can tell how it works on Linux is /dev/console is the first real
> console and it stays there. The other VTs are /dev/tty1 /dev/tty2 etc
> (or some naming like that I don't remember the exact syntax). That
> means that console messages always go to the same place.
> This is the behaviour I want and I think it is what people would expect
> based on their experiences with other systems that have VT functionality.
Yes, you're right. That way sounds better, and we'll try to update our
prototype/design to that nicer /dev/console behaviour many people are
already famililary with.
BTW, kernel messages will always go to the current active virtual
Thanks for your comments.