On Thu, Feb 16, 2012 at 08:49:05PM -0800, 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.
I agree with everything except for per-CPU buffers. I understand the
need for using printf in low-level code and it indeed complicates things.
The reason I don't like the idea of per-CPU buffers is that locking
would allow me to implement atomicity across multiple printfs.
For example I often use macros like this:
#define G_MIRROR_DEBUG(lvl, ...) do { \
if (g_mirror_debug >= (lvl)) { \
printf("GEOM_MIRROR"); \
if (g_mirror_debug > 0) \
printf("[%u]", lvl); \
printf(": "); \
printf(__VA_ARGS__); \
printf("\n"); \
} \
} while (0)
And I'd like all the printfs to be committed as one message without
using some additional buffer first and then single printf.
With some kind of printf-lock we could use recursive locking to achieve
this. In your proposal I may run each printf on different CPU.
I could eventually use sched_pin() around all printfs, I guess.
This still doesn't cover the case when I'm preempted between my printfs,
so maybe I need critical section there? I don't expect printf should be
fast, so it might be ok.
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://tupytaj.pl
pgpeHTgBnCfOi.pgp
Description: PGP signature
