svn commit: r231814 - in head/sys: kern sys

Marcel Moolenaar marcel at
Fri Feb 17 04:49:27 UTC 2012

On Feb 16, 2012, at 4:19 PM, Andriy Gapon wrote:

> on 17/02/2012 02:08 Kenneth D. Merry said the following:
> [snip]
>>>> On Thu, Feb 16, 2012 at 11:13:09 +0200, Andriy Gapon wrote:
> [snip]
>>>>> For me personally the immediate benefits in the common situations 
>>>>> outweighed the
>>>>> problems in the edge cases, although I still believe that we can get the 
>>>>> former
>>>>> without sacrifices in the latter.
> [snip]
>> It sounds fine, but I don't have sufficient time to spend on this right
>> now.  So I can either back out the changes I mentioned above (assuming we
>> get agreement from avg), or leave things as is.
> I stick to what I wrote above and so chose the status quo.
> The backout would make sense if it is immediately followed by commit of a better
> solution.  Unfortunately, a lack of time here too.

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.

The message buffer does not have to be a chunk of memory that
we circularly scribble to. It can be a per-cpu linked list of
messages even.

The advantage of thinking along these lines is that:
1.  Console output can be made optional very easily, allowing
    us to implement quiet boots without loosing the ability
    to look at messages collected during boot.
2.  Atomicity allows us to parse the messages reliably, which
    works very well in the embedded space where monitoring of
    kernel messages is common.
3.  You can decouple writing into the message buffer from
    extracting messages out of the message buffer, allowing
    the low-level console to become just another channel to
    send messages to, rather than be fundamental for printf.
4.  A linked list (for example) eliminates the problem of
    scribbling over old messages and possibly leaving partial
    output that gets misinterpreted.
5.  A per-cpu message buffer eliminates serialization to
    guarantee atomcity and with timestamping can very easily
    be turned into a sequential log.
6.  We haven't introduced complications (e.g. locking) to
    solve these problems and that make using printf in low-
    level code impossible. Thank trap handlers or interrupt

Just a thought that this may be a good time to think
bigger or broader and address more problems while we're
at it,

Marcel Moolenaar
marcel at

More information about the svn-src-head mailing list