On Fri, 17 Feb 2012, Marcel Moolenaar wrote:
On Feb 17, 2012, at 4:13 AM, Bruce Evans wrote:
On Thu, 16 Feb 2012, Marcel Moolenaar wrote:
I think we should lift above the immediate problem and allow for
single- and multi-line messages that are atomically appended to
the message buffer. Console output and propagation of messages
outside of the kernel should all come out of the message buffer
and preserving the atomicity of the messages.
This is just wrong for (low-level) console messages.
I think it actually is the right approach in that the low-level
console stops being this pivotal component that introduces
limitations for no good reason.
I like it limiting bloat. But if you really want, you can have
no limit on messages that don't go to the console imposed by
messages that do go to the console.
We need "quiet" boots, but we
also want to have boot messages available somewhere for post
mortems. Decoupling the generation and holding/storage of
Well, I want noisy boots.
messages from what you can subsequently do with them, like
displaying them, is a good thing. The decoupling allows us
to generate and store messages in the most stringent cases,
and it allows us to filter based on preference or condition.
If many cared about this, then they would have used log(9) and
perhaps added more priorities to it instead of almost always using
printf(). In the $(find /sys -name *.c) now, there are about 29457
lines matching 'printf(' (this will find slightly different
functions line sprintf() and device_printf()) and 1686 matching
'log('. printf() is just too convenient, although the only
inconvenience for using arg of log() is its extra priority arg
which helps filtering. I thought that log had a LOG_PRINTF
psuedo-prioriy to make it go to the console, but I can never
remember what its priorities are, and looking them up shows that
LOG_PRINTF is only used in removed disk code, and looking at the
source code shows that log() only goes to the console when klog
is not open. The latter is as it should be -- don't spam the
console with kernel printfs (which also go to klog, but with an
uncontrollable priority), but let syslog filter them.
It's not that hard to print messages that relates to errors
only when you have priorities or facilities or other kinds
of augmentation that help us raise awareness of the things
FreeBSD users/operators need to be aware of.
I belief the notion of a low-level console is arcane and
antiquated. Every "output" channel that can be monitored by
humans should have the possibility of being human friendly,
where human friendly is defined, for the most part, by the
the human monitoring the channel and not by us.
Console printfs is mainly for people debugging kernels. One
per day is acceptable for other purposes.
For example: I dislike our boot messages, because it's noise
to me 99.99% of the time. If I'm waiting for FreeBSD to boot
and monitor the console, I'd rather stare at the logo and a
twiddle. If I see a lot of messages scrolling by fast, I look
away (preferably at a photo of a white tropical beach, the
sea and a few palm trees).
I really like them. The scroll fast by fast enough that they are
easy to ignore. If I want to see them later, then scroll-lock
mode is usable despite its bugs. If you don't like them, then
turn them off by booting with RB_MUTE. I've never tried this of
course. As a kernel hacker, you can see the message buffer using
ddb or maybe gdb even if the boot fails.
Bruce
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "[email protected]"
