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

[Julian Elischer]

On 2/16/12 8:49 PM, Marcel Moolenaar wrote:
> 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
>      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,
that is an intersting thought.. though.. how would you sort them into 
order for
printing?

maybe a single atomic 64 bit int that is incremented per message.