All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Pascal Van Leeuwen <pvanleeuwen@insidesecure.com>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>
Subject: Re: Conding style question regarding configuration
Date: Thu, 30 May 2019 12:25:06 +0200	[thread overview]
Message-ID: <CAKv+Gu_DRDwQLuajk9TZ14vTce_1NhyU86dhtvY=-kQuvrP0AA@mail.gmail.com> (raw)
In-Reply-To: <AM6PR09MB35232561AF362BF5A9FE72FFD2180@AM6PR09MB3523.eurprd09.prod.outlook.com>

On Thu, 30 May 2019 at 12:16, Pascal Van Leeuwen
<pvanleeuwen@insidesecure.com> wrote:
>
> > >> Yes. Code and data with static linkage will just be optimized away by
> > >> the compiler if the CONFIG_xx option is not enabled, so all you need
> > >> to guard are the actual statements, function calls etc.
> > >>
> > > Ok, makes sense. Then I'll just config out the relevant function bodies
> > > and assume the compiler will do the rest ...
> > >
> >
> > No need to config out function bodies when they are static.
> >
> Well, I got a complaint from someone that my driver updates for adding PCIE
> support wouldn't  compile properly on a platform without a PCI(E) subsystem.
> So I figure I do have to config out the references to PCI specific function
> calls to fix that.
>
> Or are you just referring to bodies of static subfunctions that are no
> longer being called? Would the compiler skip those entirely?
>

The idea is that, by doing something like

static int bar;

static void foo(void)
{
    bar = 1;
}

if (IS_ENABLED(CONFIG_FOO))
    foo();

the function foo() or the variable bar don't have to be decorated with
#ifdefs or anything. The compiler will not complain that they are
unused if CONFIG_FOO is not enabled, and the contents of foo() are
always visible to the compiler, and so any programming errors will be
caught regardless of whether CONFIG_FOO is set.

  reply	other threads:[~2019-05-30 10:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-28 15:47 Conding style question regarding configuration Pascal Van Leeuwen
2019-05-28 15:51 ` Ard Biesheuvel
2019-05-28 18:51   ` Pascal Van Leeuwen
2019-05-29 16:07     ` Christophe Leroy
2019-05-30 10:16       ` Pascal Van Leeuwen
2019-05-30 10:25         ` Ard Biesheuvel [this message]
2019-06-03  7:02         ` Christophe Leroy
2019-06-03  7:14           ` Pascal Van Leeuwen
2019-05-28 16:00 ` Sandy Harris

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='CAKv+Gu_DRDwQLuajk9TZ14vTce_1NhyU86dhtvY=-kQuvrP0AA@mail.gmail.com' \
    --to=ard.biesheuvel@linaro.org \
    --cc=christophe.leroy@c-s.fr \
    --cc=linux-crypto@vger.kernel.org \
    --cc=pvanleeuwen@insidesecure.com \
    /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.