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
