Side-effect free printk?

Side-effect free printk?

[Joe Perches]

Most all printks uses do not have any side-effects.

Some however modify local or global state or perform
IO on various ports.

Things like:

drivers/video/fbdev/sa1100fb.c:	dev_dbg(fbi->dev, "DBAR1: 0x%08x\n", readl_relaxed(fbi->base + DBAR1));
drivers/remoteproc/remoteproc_core.c:	dev_err(dev, "handling crash #%u in %s\n", ++rproc->crash_cnt,

CONFIG_PRINTK can be set to 'n', but all direct printk
calls still evaluate their arguments.

These calls can unnecessarily increase code size.

Some printk using macros are defined like:

#define foo_dbg(fmt, ...)	\
do {				\
	if (0)			\
		printk(...);	\
} while (0)

The compiler can optimize any use away so this can
eliminate any side-effect.

For the general case, printk arguments that call
functions that perform simple calculations should not
qualify unless there is some global state change or
additional IO.

So, with the goal of elimination of side-effects from
as many of the printks as possible (and the eventual
removal of all of the side-effects), is it possible to
use coccinelle to list all printk calls that have
side-effects in their arguments?

It seems coccinelle would need the entire source tree
to do this, so I'm not sure it's possible, but it
doesn't hurt to ask...

Re: Side-effect free printk?

[Julia Lawall]

On Wed, 3 Dec 2014, Joe Perches wrote:

> Most all printks uses do not have any side-effects.
>
> Some however modify local or global state or perform
> IO on various ports.
>
> Things like:
>
> drivers/video/fbdev/sa1100fb.c:	dev_dbg(fbi->dev, "DBAR1: 0x%08x\n", readl_relaxed(fbi->base + DBAR1));
> drivers/remoteproc/remoteproc_core.c:	dev_err(dev, "handling crash #%u in %s\n", ++rproc->crash_cnt,
>
> CONFIG_PRINTK can be set to 'n', but all direct printk
> calls still evaluate their arguments.
>
> These calls can unnecessarily increase code size.
>
> Some printk using macros are defined like:
>
> #define foo_dbg(fmt, ...)	\
> do {				\
> 	if (0)			\
> 		printk(...);	\
> } while (0)
>
> The compiler can optimize any use away so this can
> eliminate any side-effect.
>
> For the general case, printk arguments that call
> functions that perform simple calculations should not
> qualify unless there is some global state change or
> additional IO.
>
> So, with the goal of elimination of side-effects from
> as many of the printks as possible (and the eventual
> removal of all of the side-effects), is it possible to
> use coccinelle to list all printk calls that have
> side-effects in their arguments?
>
> It seems coccinelle would need the entire source tree
> to do this, so I'm not sure it's possible, but it
> doesn't hurt to ask...

I'm not completely sure to understand the question.  The following
is certainly possible:

printk(...,\(x++\|x--\|++x\|--x\),...)

Of course one would want to have a lot more operators than the ones shown.
(As a side note, we are planning to add a metavariable for arithmetic and
side-effecting operators, which will make this sort of thing much
simpler.)

When you say "have the entire source tree", do you mean things like:

printk(..., foo(x));

where it is not clear whether foo performs a side effect or not?  That
could indeed be harder to detect.

Perhaps the most relevant case is when there is a definition in the same
file, typically a macro in a header file.  It could still be complicated
to make a pattern that would match all of the possibilities.

julia

Re: Side-effect free printk?

[Joe Perches]

On Wed, 2014-12-03 at 19:02 +0100, Julia Lawall wrote:
> 
> On Wed, 3 Dec 2014, Joe Perches wrote:
> 
> > Most all printks uses do not have any side-effects.
> >
> > Some however modify local or global state or perform
> > IO on various ports.
> >
> > Things like:
> >
> > drivers/video/fbdev/sa1100fb.c:	dev_dbg(fbi->dev, "DBAR1: 0x%08x\n", readl_relaxed(fbi->base + DBAR1));
> > drivers/remoteproc/remoteproc_core.c:	dev_err(dev, "handling crash #%u in %s\n", ++rproc->crash_cnt,
> >
> > CONFIG_PRINTK can be set to 'n', but all direct printk
> > calls still evaluate their arguments.
> >
> > These calls can unnecessarily increase code size.
> >
> > Some printk using macros are defined like:
> >
> > #define foo_dbg(fmt, ...)	\
> > do {				\
> > 	if (0)			\
> > 		printk(...);	\
> > } while (0)
> >
> > The compiler can optimize any use away so this can
> > eliminate any side-effect.
> >
> > For the general case, printk arguments that call
> > functions that perform simple calculations should not
> > qualify unless there is some global state change or
> > additional IO.
> >
> > So, with the goal of elimination of side-effects from
> > as many of the printks as possible (and the eventual
> > removal of all of the side-effects), is it possible to
> > use coccinelle to list all printk calls that have
> > side-effects in their arguments?
> >
> > It seems coccinelle would need the entire source tree
> > to do this, so I'm not sure it's possible, but it
> > doesn't hurt to ask...
[]
> When you say "have the entire source tree", do you mean things like:
> 
> printk(..., foo(x));
> 
> where it is not clear whether foo performs a side effect or not?  That
> could indeed be harder to detect.

Yes, exactly.

The ++/-- stuff is trivial.
grep can find those easily enough.

printf vs. printk (was Re: Side-effect free printk?)

[Pavel Machek]

Hi!

BTW... All the time I'm programming in kernel, I use printf(), and
when hacking userspace, I use printk().

Nasty.

Given that printf() and printk() have exactly the same behaviour,
could we allow printf() in kernel? Now... printk()s are usually
removed before merging the driver, so code will not see much change,
but it will certainly result in less 4-letter words while developing.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: printf vs. printk (was Re: Side-effect free printk?)

[Joe Perches]

On Fri, 2014-12-05 at 11:32 +0100, Pavel Machek wrote:
> Hi!
> 
> BTW... All the time I'm programming in kernel, I use printf(), and
> when hacking userspace, I use printk().
> 
> Nasty.
> 
> Given that printf() and printk() have exactly the same behaviour,
> could we allow printf() in kernel? Now... printk()s are usually
> removed before merging the driver, so code will not see much change,
> but it will certainly result in less 4-letter words while developing.

My preference would be to eventually eliminate printk
altogether but I don't see a real problem adding 
	#define printf printk
to include/linux/printk.h

but

Re: printf vs. printk (was Re: Side-effect free printk?)

[Joe Perches]

On Fri, 2014-12-05 at 07:24 -0800, Joe Perches wrote:
> My preference would be to eventually eliminate printk
> altogether but I don't see a real problem adding 
> 	#define printf printk
> to include/linux/printk.h
> 
> but

(bah, bad touchpad)

but I'm not going to write or ack that patch.