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.
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
