Subject: Re: DAD verbosity
To: Chris G. Demetriou <>
From: Darren Reed <>
List: tech-kern
Date: 02/17/2000 14:01:52
In some email I received from Chris G. Demetriou, sie wrote:
> Darren Reed <> writes:
> > In some email I received from matthew green, sie wrote:
> > > yunno, all this run as threads, etc, stuff that we have now makes for
> > > annoying console/kernel messages.  things are printed in the middle of
> > > other things.  last time i updated my lapdog and booted with both an
> > > ep and a xircom ether+modem card, the ep0 and com2 probes printed
> > > all over each other so much that i was very unsure about what applied
> > > to what, and looked really ugly (the lapdog is dead right now)...
> > > 
> > > 
> > > i wonder, is there any nice way to ensure these messages are printed
> > > in a sane fashion?  it is really annoying :-(
> > 
> > console output should be serialized, curtesy of locking...
> console output _is_ serialized, courtesy of locking.
> printf("foo bar baz") won't have other stuff interspersed in it (or at
> least, won't if there aren't bugs 8-).
> However, what's the right thing to do for
> 	printf("foo "); printf("bar "); printf("baz");
> right now, each of those separately acquires and releases the relevant
> lock, and so can be split up.


> It's not obvious to me how to tell, in a safe and sane way, the kernel
> printf bits to 'group' those so they're printed out together, but the
> kernel (esp in the autoconf code) isn't structured so that all of the
> places which print related stuff can be coalesced into a single kernel
> printf call...

If it's important, then each line should have a prefix in the string.

e.g. IP Filter prints a few statements out when it initializes and each
line starts with "IP Filter".  It may use up extra bytes, but there is
no confusion.

IMO, device drivers should start printf lines with "<devicename>#:" and
so on.  If it is DAD for ep0 and de0 under IPv6, maybe it should be
"ep0:IPv6:DAD: no duplicates found" ?

This also makes later analysis easy with grep, etc.  Maybe use of printf
in the kernel like this should be a part of KNF.  The probe messages from
bootup should not pose a problem - they appear to be mostly instantly
recognisable anyway.