A sort of plan for consoles in FreeBSD

[M. Warner Losh]

In message: <1471.1148836757 at critter.freebsd.dk>
            "Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
: In message <4479D804.1060106 at elischer.org>, Julian Elischer writes:
: >M. Warner Losh wrote:
: >
: >>In message: <4479C171.4050403 at elischer.org>
: >>            Julian Elischer <julian at elischer.org> writes:
: >>: killing XConsole is not a small matter. people have that when they are 
: >>: specifically looking for that information
: >>
: >>Recall that this is only for programs that open /dev/console directly
: >>and write to it, like syslogd.
: >
: >the description makes it sound like xconsole would not be able to show 
: >kernel error messages.
: 
: xconsole is a hack anyway.
: 
: the correct way would be to have way to connect to syslogd and subscribe
: to messages.

There's no way to 'connect to syslogd and subscribe to messages' in
the current syslogd.  In today's world order, the best that it can do
is to open a pty, and then hack syslogd.conf to send messages to that
pty and then log the results.  This takes quiet a bit of code, and
there's a number of tricky edge cases to make it work.  At least there
were back when I created a combination xconsole + syslog display
program.  And I still didn't have the ability to filter on message
time except in real time (since syslogd doesn't print message type).
I also had to have two PTYs open (one for syslog messages and one for
console messages).  If you are going to go down this route, lots of
work needs to happen to both xconsole and syslogd (and all other
xconsole-like programs).

Not saying that it can't be done, but there's a big hunk of work there
before people would be happy.

Why we can't do as I suggested earlier and just make /dev/console a
pseudo-pipe that is fed from #2 and #4 and that has a well documented
'other end interface' for things like xconsole.  that would simulate
the historical usage of /dev/console well.

Warner