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

[Andriy Gapon]

Since this issue has generated a sudden interest, I would like to use this
opportunity to point my older proposal as well:
http://lists.freebsd.org/pipermail/freebsd-arch/2011-August/011405.html

Essentially the algorithm is:
1. atomically (CAS) reserve a space in the message data buffer
2. output full message to the reserved space (no contention here)
3. atomically (CAS) append a pointer to the message in the message pointers buffer

on 17/02/2012 06:49 Marcel Moolenaar said the following:
> 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
>     handlers.
> 
> Just a thought that this may be a good time to think
> bigger or broader and address more problems while we're
> at it,
> 


-- 
Andriy Gapon