All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Darren Hart <dvhart@infradead.org>,
	ibm-acpi-devel@lists.sourceforge.net,
	platform-driver-x86@vger.kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] thinkpad_acpi: Remove side effects from vdbg_printk -> no_printk macro
Date: Wed, 26 Aug 2015 11:35:25 -0700	[thread overview]
Message-ID: <1440614125.2780.33.camel@perches.com> (raw)
In-Reply-To: <1440613632.3433387.366841089.60E02F29@webmail.messagingengine.com>

On Wed, 2015-08-26 at 15:27 -0300, Henrique de Moraes Holschuh wrote:
> On Wed, Aug 26, 2015, at 15:13, Joe Perches wrote:
> > vdbg_printk when not using CONFIG_THINKPAD_ACPI_DEBUG uses
> > no_printk which produces no logging output but always
> > evaluates arguments.
> > 
> > Change the macro to surround the no_printk call with
> > 	do { if (0) no_printk(...); } while (0)
> > to avoid the unnecessary argument evaluations.
> > 
> > $ size drivers/platform/x86/thinkpad_acpi.o*
> >    text       data     bss     dec     hex filename
> >   60918      6184     824   67926   10956
> >   drivers/platform/x86/thinkpad_acpi.o.new
> >   60927      6184     824   67935   1095f
> >   drivers/platform/x86/thinkpad_acpi.o.old
> 
> The code size savings of this change are really small...

yup.  This is just an on-the-way patch to get
all the no_printk uses in a state that can
be converted more simply to a side-effect free
mechanism.

> > --- a/drivers/platform/x86/thinkpad_acpi.c
> > +++ b/drivers/platform/x86/thinkpad_acpi.c
> > @@ -402,7 +402,7 @@ static const char *str_supported(int is_supported);
> >  #else
> >  static inline const char *str_supported(int is_supported) { return ""; }
> >  #define vdbg_printk(a_dbg_level, format, arg...)        \
> > -       no_printk(format, ##arg)
> > +       do { if (0) no_printk(format, ##arg); } while (0)
> >  #endif
> 
> And won't this change disable compile-time checking of 'format ## arg'
> for issues?

No.  The call is still there so the compiler checks
the format/argument matches, but eliminates the
call and any side-effect calls from the object file.

  reply	other threads:[~2015-08-26 18:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-26 18:13 [PATCH] thinkpad_acpi: Remove side effects from vdbg_printk -> no_printk macro Joe Perches
2015-08-26 18:27 ` Henrique de Moraes Holschuh
2015-08-26 18:35   ` Joe Perches [this message]
2015-08-27 17:32     ` Henrique de Moraes Holschuh
     [not found] ` <1440612818.2780.24.camel-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
2015-08-27 17:33   ` Henrique de Moraes Holschuh
2015-08-27 17:33     ` Henrique de Moraes Holschuh
2015-08-28 17:50     ` Darren Hart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1440614125.2780.33.camel@perches.com \
    --to=joe@perches.com \
    --cc=dvhart@infradead.org \
    --cc=hmh@hmh.eng.br \
    --cc=ibm-acpi-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.