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

Pawel Jakub Dawidek pjd at
Fri Feb 17 09:00:02 UTC 2012

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             
FreeBSD committer               
Am I Evil? Yes, I Am!           
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url :

More information about the svn-src-head mailing list