On Linux, you can turn on/off kernel message generated by 'printk()'
on any terminal with 'dmesg' command.
I think it's a useful feature.

Riny Qian wrote:
> 
> 
> 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.
> 
> I just took a quick look at Linux. On Linux, /dev/console is NOT a real
> console, and all messages output via /dev/console does go to the current
> active VT, it's not 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.
>>
> 
> There are some differences among other systems (e.g. our older Solaris
> and Linux, we'll take a look at other systems).
> 
> Considering your abovementioned special case, now I prefer the policy of
> our older Solaris, that is, /dev/console is a primary real console, and
> VTs are just additional console terminals for users. Thus console
> messages always go to the same place, and kernel messages also can
> always go to the primay console (or some fixed virtual console).
> 
> I'd like to hear more people's comments on this policy/behaviour
> before final design.
> 
> thanks,
> Riny
> 
> 
> 
> _______________________________________________
> vconsole-discuss mailing list
> vconsole-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/vconsole-discuss

Reply via email to