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

Thanks for your comments.

Riny


Reply via email to