From owner-freebsd-hackers Mon Jan 27 19:31:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA13458 for hackers-outgoing; Mon, 27 Jan 1997 19:31:21 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA13442 for ; Mon, 27 Jan 1997 19:31:17 -0800 (PST) Received: (qmail 7563 invoked by uid 1000); 28 Jan 1997 04:30:21 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199701272244.PAA15452@seagull.rtd.com> Date: Mon, 27 Jan 1997 20:21:06 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: Don Yuniskis Subject: Re: suggestion for kernel printk() ? Cc: bde@zeta.org.au, freebsd-hackers@freefall.freebsd.org Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Don Yuniskis; On 27-Jan-97 you wrote: > 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). Unfortunately, this makes some sense, as there are no interrupts during some of this. I solved this porblems on a SVR4.2 port by providing the UART witha polled mode. Added a walloping 20 lines of code to the driver. What that means in a PC console I really do not know. Real computers should have only serial consoles. Preferebly an LA34. Right? :-) > > > 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 I am so new to FreeBSD that I did not even see that there is a printk(). How does that relate to printf() is see everywhere? Simon