From owner-freebsd-hackers  Sun Jan 26 00:35:58 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id AAA26871
          for hackers-outgoing; Sun, 26 Jan 1997 00:35:58 -0800 (PST)
Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA26858
          for <freebsd-hackers@freefall.freebsd.org>; Sun, 26 Jan 1997 00:35:56 -0800 (PST)
Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id BAA01692; Sun, 26 Jan 1997 01:35:51 -0700 (MST)
From: Don Yuniskis <dgy@rtd.com>
Message-Id: <199701260835.BAA01692@seagull.rtd.com>
Subject: Re: suggestion for kernel printk() ?
To: bde@zeta.org.au (Bruce Evans)
Date: Sun, 26 Jan 1997 01:35:50 -0700 (MST)
Cc: bde@zeta.org.au, dgy@rtd.com, freebsd-hackers@freefall.freebsd.org
In-Reply-To: <199701260649.RAA20345@godzilla.zeta.org.au> from "Bruce Evans" at Jan 26, 97 05:49:48 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> >> I use a serial console and `terminalprogram | tee foo' to capture
> >> the output.
> >
> >Yes, but I would have had to have built the kernel with COMCONSOLE
> >(which I didn't).
> 
> COMCONSOLE hasn't been necessary for 2 years in -current (just boot
> with -h) but is still necessary in -stable.  Sigh.

Hmmm... this is a 2.1R box.  I'll have to check next time I reboot...

> >However, is it worthwhile for the mechanism that printk()  ?? uses to
> >observe some kind of flow control?  It did not recognize scroll_lock,
> >pause, ^S, etc.  This would have at least enabled me to read some
> >(i.e. one screen full) of the messages to see what the kernel was
> >complaining about.
> 
> Scroll lock and scrollback don't work until interrupts are enabled after

Yes, that's what I had suspected.

> probing all the devices.  printf() doesn't have any flow control.  It
> can't afford to pause once the system is up because that would freeze
> the whole system.  Freezing for 1 msec per character to for output at
> 9600 bps is bad enough.

But would it actually *break* anything?  Perhaps I'll hack in a two line
patch next time I rebuild a kernel and see what happens...

Thx!
--don