[ On Mon, January 4, 1999 at 16:35:03 (-0800), Curt Sampson wrote: ]
> Subject: Re: troubles with serial console support....
>
> On Sun, 3 Jan 1999, Greg A. Woods wrote:
> >
> > Also, in modern day machines with syslog it's rarely helpful to print
> > messages to the console, especially when that console is not a printing
> > terminal....
> 
> I beg to differ. When some parts of a machine get well and truly
> wedged, a kernel printf may still work. And I log all the console
> output using Vixie's rtty package.

One of the things I've been considering experimenting with is adding
low-level syslog-to-network support to the kernel for kernel printfs.

One of the problems with kernel printfs in NetBSD is that they are
effectivley useless on the consoles of i386 machines running X11, unlike
Suns to a certain extent, for example.

Perhaps with the recent appearance of more reliable kernel thread
support it would be possible to get kernel console drivers to run as a
separate thread with separate interrupt contexts such that even if the
system becomes irretrivably wedged it will still be possible to send
syslog messages to the network and to allow users to switch back to the
true console screen and view (possibly through a scroll-back buffer) the
recent kernel messages.

Using something like "rtty" or "screen" as a means of providing a simple
console concentrator/terminal server is a good idea (and the particular
architecture is irrelevant, so long as it's possible to provide some
sort of hard-wired console terminal connection to an separate and
autonomous device, but isn't exactly what I was talking about,
especially since it imposes a potential bottleneck that's far more
restricted than a network syslog server might be for for normal syslog
output.  It also doesn't really help any in the situation we were
discussing since incorrect cabling or disabling of the "rtty" or
"screen" host will present an equally bad situation to the server in
question.  (I.e. you're not much better off blocking syslog output than
you are blocking kernel output!)  The real solution is to use a
non-blocking (and hopefully reliable) mechanism for syslog logging, and
to make sure that *only* kernel printfs go to the true physical console
under normal operating conditions.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>