Date: Sat, 18 Feb 2012 06:20:34 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: marcel@freebsd.org, Eitan Adler <eadler@freebsd.org>, svn-src-all@freebsd.org, "Kenneth D. Merry" <ken@freebsd.org>, Andriy Gapon <avg@freebsd.org>, src-committers@freebsd.org, Bruce Evans <brde@optusnet.com.au>, svn-src-head@freebsd.org, Julian Elischer <julian@freebsd.org> Subject: Re: svn commit: r231814 - in head/sys: kern sys Message-ID: <20120218050858.Q4138@besplex.bde.org> In-Reply-To: <2CDFAEC9-D57A-4513-96D1-8A78D27E8696@xcllnt.net> References: <201202160511.q1G5BZNk099785@svn.freebsd.org> <20120216181210.K1423@besplex.bde.org> <4F3CC40D.4000307@freebsd.org> <4F3CC5C4.7020501@FreeBSD.org> <4F3CC8A5.3030107@FreeBSD.org> <20120216174758.GA64180@nargothrond.kdm.org> <20120217053341.R1256@besplex.bde.org> <20120217000846.GA7641@nargothrond.kdm.org> <4F3D9D03.6020507@FreeBSD.org> <9CB7ECE8-FF10-43BE-9EBD-16953BE3B193@xcllnt.net> <20120217191017.U1871@besplex.bde.org> <2CDFAEC9-D57A-4513-96D1-8A78D27E8696@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120218050858.Q4138>