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 _______________________________________________ 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"