[ On , June 14, 2002 at 19:13:29 (-0000), eeh@netbsd.org wrote: ]
> Subject: Re: patch for wscons scrolling
>
> | [ On , June 14, 2002 at 14:47:13 (-0000), eeh@netbsd.org wrote: ]
> | > Subject: Re: patch for wscons scrolling
> | >
> | > 
> | > | For kernel options, I would use #ifdef clauses in code to avoid
> | > | compiling something that people may not want ;) Be careful to set NULL
> | > | pointers in vga structures when kernel option is disabled.
> | > 
> | > Why does scrollback need to be inside the kernel anyway?
> |
> | Huh?  We're talking about kernel printf's here!!!!

(I should have added the qualifier "primarily" in there somewhere...)

> Yeah?  So?  xconsole is quite happy to redirect kernel printfs wherever
> you want.  And if you really want that stuff saved then use dmesg.

Most of my kernel printf's appear _LONG_ before xconsole gets started,
and many times that's because there never will be and Xserver to run it
on!

There are also all those pesky messages that can appear on /dev/console
_only_ (and also long before xconsole might ever run) due to /sbin/init
redirecting stdout there (and thus that's where all the /etc/rc stuff is
sent).

Now it would be nice if everything written to /dev/console were also
written to /dev/klog so it could be logged under normal operating
conditions, but that just isn't happening yet either (at least not on
NetBSD :-), so wscons scroll back can be extremely critical even when
(attempting to) take a machine to multi-user mode too.  Still that's
assuming the system gets to the point where syslogd can successfully
open and read the data from /dev/klog and then turn around and
successfully open and write it to some disk file too!

dmesg is nice (assuming you also have "more" or "less" too), but it
isn't the be-all and end-all of solutions.  There are no guarantees a
failing system will allow you to run dmesg (and "more" or "less" or some
full-screen editor or other tool for selective display, etc.), let alone
even mount any disk.  There's a nice big buffer full of data in the
kernel, and there's a nifty console screen driver which has already been
used to display the data that's gone into that buffer and now with the
addition of the code being discussed all you'll need are working
keyboard interrupts in order to be able to scroll back over that data
using the console screen driver.  All we need to do now is choose which
keys on which implementations will be the officially sanctioned defaults
and get the heck on with it!

(and if you or anyone else really hates this code then don't compile it
into _your_ kernels -- but please don't put a damper on everyone else's
party!  this feature is _LONG_ past due in NetBSD, and maybe someday
every workstation with more than ~4MB of RAM will be able to make use of
wscons and thus give its operator the warm fuzzy comfort of knowing that
at least some console output can _ALWAYS_ be reviewed even after it has
scrolled off the display screen!)

-- 
								Greg A. Woods

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