Date: Mon, 27 Jan 1997 20:21:06 -0800 (PST) From: Simon Shapiro <Shimon@i-Connect.Net> To: Don Yuniskis <dgy@rtd.com> Cc: bde@zeta.org.au, freebsd-hackers@freefall.freebsd.org Subject: Re: suggestion for kernel printk() ? Message-ID: <XFMail.970127203021.Shimon@i-Connect.Net> In-Reply-To: <199701272244.PAA15452@seagull.rtd.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970127203021.Shimon>