From owner-freebsd-hackers Mon Jan 27 17:23:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA02924 for hackers-outgoing; Mon, 27 Jan 1997 17:23:08 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA02897 for ; Mon, 27 Jan 1997 17:23:03 -0800 (PST) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id OAA27491 for ; Mon, 27 Jan 1997 14:49:48 -0800 (PST) Received: from seagull.rtd.com by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0vozqO-0008yFC; Mon, 27 Jan 97 14:48 PST Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id PAA15452; Mon, 27 Jan 1997 15:44:19 -0700 (MST) From: Don Yuniskis Message-Id: <199701272244.PAA15452@seagull.rtd.com> Subject: Re: suggestion for kernel printk() ? To: Shimon@i-Connect.Net (Simon Shapiro) Date: Mon, 27 Jan 1997 15:44:19 -0700 (MST) Cc: dgy@rtd.com, freebsd-hackers@freefall.freebsd.org, bde@zeta.org.au In-Reply-To: from "Simon Shapiro" at Jan 27, 97 02:23:10 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 It seems that Simon Shapiro said: > > > > I just spent some time fighting a kernel that died miserably > > > >on boot :-( I was inundated with an endless stream of kernel > > > >messages (in highlighted text) followed promptly by a hard reset. > > > >It was quite frustrating to find that there doesn't seem to be a > > > >mechanism to pause the display at this point! > > > > 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. > > I may be offbase here, but scroll-lock, etc. are INPUT, while printk is Yes. But all of those mechanisms tie in to provide flow control for regular console output functions. Apparently, however, this happens at a higher level than I had hoped/assumed (i.e. more stuff has to be functional before this mechanism works). > output. No? Maybe a (oops :-) SysV-like mechanism where print{kf} go to > a circular buffer andanother mechanism dumps it to ``the console''. > If you like ugly, (if memory serves), you can either pass an additional arg > to the output routine (A la Linux) or designate the first character in the > string to tell what to do, as in ~==console and buffer, !=bufferonly, etc. I was suggesting having printk() examine the keyboard buffer for a pending "pause" key and blocking in this event. However, it appears that the system couldn't handle that crude of an implementation... --don