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
