Re: [PATCH] Fix bytecount result from printk()

[Andi Kleen]

"David S. Miller" <davem@xxxxxxxxxxxxx> writes:

> From: Dave Jones <davej@xxxxxxxxxx>
> Date: Thu, 1 Dec 2005 12:57:32 -0500
> 
> > On Thu, Dec 01, 2005 at 10:55:49AM -0500, Mark Lord wrote:
> >  > printk() returns a bytecount, which nothing actually appears to use.
> > 
> > We do check it in a few places.
> > 
> > arch/x86_64/kernel/traps.c:                             i += printk(" "); \
> > arch/x86_64/kernel/traps.c:                     i += printk(" <%s> ", id);
> > arch/x86_64/kernel/traps.c:                     i += printk(" <EOE> ");
> > arch/x86_64/kernel/traps.c:                             i += printk(" <IRQ> ");
> > arch/x86_64/kernel/traps.c:                             i += printk(" <EOI> ");
> > drivers/char/mem.c:             ret = printk("%s", tmp);
> 
> Wow, that's amazing. :)

Taking the blame.

> I bet these can easily be removed, and since printk() is such
> a core thing, simplifying it should trump whatever benfits
> these few call sites have from getting a return byte count.

I used it for linewrapping in the oops output.

Actually I would expect more users from sprintf and snprintf
(e.g. common in /proc output to compute the return value of the read) 
and that is exactly the same code path.

If you do the same grep for sn?printf I bet there will be much more hits.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/