[ On Thursday, October 19, 2000 at 14:10:05 (-0400), Andrew Brown wrote: ]
> Subject: Re: why syslog(3) must not try to write to /dev/console....
>
> >Yes, I know -- it sounds gross.  It's not an optimal solution.  But think
> >about it.  If we're a kernel, and we REALLY need to send something THAT
> >badly, are we gonna respect flow control?
> 
> not a good idea, i think.  if the console is spewing fascinating
> messages about what happened to make it so crazy faster than i can
> read them, you'd better bet that i wanna use flow control to stop it
> long enough for me to read it.

Indeed -- that's exactly why it will take lots of hard thought and
careful consideration to come up with a safe but usable alternative to
simply letting the kernel get all bunged up!

As I recall from the last time I looked at the msgbuf code in the kernel
it may not be that easy to do, but one idea I've considered is to allow
the kernel to write to msgbuf while output is blocked and to then flush
old output in a FIFO manner.  In order to actually get somewhere the
first time the FIFO fills and somthing's about to be flushed the kernel
could try asking the underlying tty driver to toggle any flow control
and try to drain or flush the most recent line of output.

This would suggest though that all kernel output should go directly into
the msgbuf buffer and then have a separate kernel thread trying to write
any new output to the console device.  This thread could take care of
timeouts, flushing old data that never made it to the device, etc.,
while the rest of the kernel would be free to send output without ever
worrying about blocking.

Meanwhile it would be terribly nice if NetBSD were to acquire buffering
and scroll-back features in the console terminal emulator code for those
systems that use video consoles.  This is an enormously valuable feature
in FreeBSD!  If wscons is to take over such duties on all ports then
this would be the ideal place for such a feature.  (I'd sure like to
have multiple virtual consoles on all of my non-i386 machines too, since
then I could keep the real /dev/console on a non-GUI "screen".

There are also implications here for servicing the needs of programs
like xconsole that wish to capture all console output.  IIRC the console
driver code is responsible for allowing this, but in the world of wscons
I'm hoping that all it does is to capture a copy of such output.  In
theory it would be possible to write to a program like xconsole even
while the real /dev/console is blocked by whatever means.

Finally why can't wscons work for serial consoles too!  :-)

It would be like having "screen" built right into the kernel, and I
suspect it wouldn't take very much more effort either since wscons
itself already has the emulation and multi-view features.  This would
make it possible to truly use a modem directly on the console since
wscons would save new output in its scroll-back buffer while DCD was
low, doing a refresh on reattachment.  It would also make it relatively
trivial to add an ioctl() to the console driver that would allow you to
switch the console from one serial device to another (in much the same
way SysVr3.x allows).  Finally this would even make it possible to
dynamically flip from a video to serial console and back!

So much work -- so little time!

-- 
							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>