A sort of plan for consoles in FreeBSD

[Julian Elischer]

Poul-Henning Kamp wrote:

>In message <20060528.011518.1306332021.imp at bsdimp.com>, "M. Warner Losh" writes
>:
>  
>
>>In message: <16029.1148764704 at critter.freebsd.dk>
>>           Poul-Henning Kamp <phk at phk.freebsd.dk> writes:
>>: 4. The /dev/console device in multi-user mode.
>>:     Emergency output device for critical messages.
>>
>>Who is generating these messages?
>>    
>>
>
>Typically programs in distress.
>
>  
>
>>If so, why not make /dev/console a pipe that syslogd listens to?
>>    
>>
>
>That is the option which I personally favour.
>
>It kills xconsole(1) like applications, and I suspect that would
>result in whinage, but if we are willing to do that, it is by
>far the simplest and most sensible solution.
>  
>
killing XConsole is not a small matter. people have that when they are 
specifically looking for that information

>  
>
>>: I would like to redefine the semantics of "/dev/console" as follows:
>>: 	if any console-consumers like xconsole(8) are active
>>: 		send output to all console-consumers.
>>: 	else if a controlling terminal is available
>>: 		send output to controlling terminal (that is /dev/tty)
>>: 	else
>>: 		send output to syslogd, as if generated by printf(9).
>>: 		(but do not actually output to low-level console)
>>
>>Assuming that this is for #4 /dev/console, that's fine.
>>    
>>
>
>It is only #4.
>
>  
>
>>The problem that I
>>have with it being just /dev/tty is that the program opened
>>/dev/console to tell the world about it, rather than just using
>>fprintf(stderr,).  What does that gain you?
>>    
>>
>
>As I said in the other email, /dev/tty and stderr is not quite the
>same thing.  /dev/tty has more of the semantics that /dev/console
>used to have (ie: flash it before their eyes).
>
>  
>