A sort of plan for consoles in FreeBSD

[Poul-Henning Kamp]

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.

>: 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).

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.