mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Steve French" <smfrench@gmail.com>
To: "Sam Ravnborg" <sam@ravnborg.org>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: optimizing out inline functions
Date: Thu, 29 May 2008 11:39:32 -0500	[thread overview]
Message-ID: <524f69650805290939v65f9f5b8m65fd1ba23acd08d8@mail.gmail.com> (raw)
In-Reply-To: <20080528200057.GA7300@uranus.ravnborg.org>

Ran into one loosely related question, printk takes a variable
argument list, so the calling function in this case would also need to
be able to handle thos variable arguments.  With macros, we are able
to do things like with variable arguments easily

#define function_to_print_some_warning(format, arg...)
printk(KERN_WARNING ": " format "\n" , ## arg)

Are there style rules (or nicely written examples) for doing this
(variable argument lists) with (inline) functions

On Wed, May 28, 2008 at 3:00 PM, Sam Ravnborg <sam@ravnborg.org> wrote:
> On Wed, May 28, 2008 at 02:51:02PM -0500, Steve French wrote:
>> In trying to remove some macros, I ran across another kernel style
>> question.  I see two ways that people try to let the compiler optimize
>> out unused code and would like to know which is preferred.  The first
>> example uses an empty inline function and trusts the compiler will
>> optimize it out.
>>
>> #ifdef CONFIG_DEBUG_SOMETHING
>> static inline void some_debug_function(var1)
>> {
>>     something = var1;
>>     printk(some debug text);
>> }
>> #else
>> static inline void some_debug_function(var1)
>> {
>>    /* empty function */
>> }
>> #endif
>
> With reference to a recent thread about kconfig
> I would prefer:
> static inline void some_debug_function(var1)
> {
>        if (KCONFIG_DEBUG_SOMETHING) {
>                something = var1;
>                printk(some debug text);
>        }
> }
>
>
> But we do not have KCONFIG_DEBUG_SOMETHING available
> so the second best is to use an empty function
> to keep the typechecking in place.
>
> IIRC gcc optimize both away.
>
>        Sam
>



-- 
Thanks,

Steve

  reply	other threads:[~2008-05-29 16:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-28 19:51 Steve French
2008-05-28 19:54 ` Pekka Enberg
2008-05-29  8:40   ` Andrew Morton
2008-05-28 20:00 ` Sam Ravnborg
2008-05-29 16:39   ` Steve French [this message]
2008-05-29 17:20     ` Sam Ravnborg
2008-06-02  9:38     ` Vegard Nossum
     [not found] <ayzYV-7mv-5@gated-at.bofh.it>
     [not found] ` <ayA8E-89e-29@gated-at.bofh.it>
2008-05-28 20:37   ` James Kosin
2008-05-29  3:27     ` Johannes Weiner
2008-05-29  3:04       ` Joe Perches
2008-05-29 13:11       ` James Kosin
2008-05-29 13:13       ` James Kosin

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=524f69650805290939v65f9f5b8m65fd1ba23acd08d8@mail.gmail.com \
    --to=smfrench@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@ravnborg.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®