All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
To: u-boot@lists.denx.de
Subject: [PATCH] common/board_f.c: use #ifdefs a little more consistently
Date: Fri, 28 Feb 2020 17:24:58 +0000	[thread overview]
Message-ID: <1500fa23-9959-76cc-0b3e-148a22cd46da@prevas.dk> (raw)
In-Reply-To: <20200228154620.GJ18302@bill-the-cat>

On 28/02/2020 16.46, Tom Rini wrote:
> On Fri, Feb 28, 2020 at 08:42:21AM +0000, Rasmus Villemoes wrote:
>> On 28/02/2020 00.40, Simon Glass wrote:

>>> Using if() is preferable to #if if there is no cost.
>>
>> Completely agree, and I also prefer to have the linker eliminate unused
>> functions rather than cluttering the C code with #ifdefs. But that can't
>> be used in this case.
>>
>> Anyway, this wasn't primarily to save 112 bytes or whatnot from the
>> U-Boot image, just to use one style a little more consistently.
> 
> Perhaps we could come up with a little more macro-magic?  In
> psuedo-code:
> #define RESERVE_INIT_SEQ_F_ENTRY(fn) \
> #if CONFIG_IS_ENABLED(toupper(fn))
> reserve_##fn
> #endif
> #endif

I'm afraid that's rather far from something that can be implemented;
macros cannot expand to other preprocessor directives, and toupper is
also pretty hard to do.

What we could do if we want to reduce #ifdefs while still eliminating
the no-op functions is to replace

#ifdef CONFIG_FOO
static int foo_init(void) {
  blabla;
  return 0;
}
#endif
...
init_sequence_f[] = { ...
#ifdef CONFIG_FOO
  foo_init,
#endif
...
}

by

static int foo_init(void) { /* always defined */
  blabla;
  return 0;
}

init_sequence_f[] = { ...
  IS_ENABLED(CONFIG_FOO) ? foo_init : NULL,
...
}

and teach the iterator to ignore NULL entries (I don't remember if we
use a NULL terminator or use ARRAY_SIZE; if the former one should switch
to the latter). It will still cost sizeof(void*) for the NULL entries,
but the function bodies (and on powerpc the .fixups) should be
eliminated, and there's not an #ifdef in sight.

If one also wants to get rid of those NULL entries, I did
https://lore.kernel.org/lkml/1444165543-2209-1-git-send-email-linux at rasmusvillemoes.dk/
a long time ago (see the COND_INITIALIZER()), but whether that can be
tweaked to still automatically avoid a "defined but not used" warning I
don't know.

> And then a little harder thinking about negative-case (OF_EMBED) ?  Or
> just have those be the few ifndef's?

That can be done in the same manner by just switching second and third
operand.

The problem is the function bodies which rely on symbols (for example
CONFIG_* values) that only exist if CONFIG_FOO.

Rasmus

  reply	other threads:[~2020-02-28 17:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-27  8:18 [PATCH] common/board_f.c: use #ifdefs a little more consistently Rasmus Villemoes
2020-02-27 23:40 ` Simon Glass
2020-02-28  8:42   ` Rasmus Villemoes
2020-02-28 15:46     ` Tom Rini
2020-02-28 17:24       ` Rasmus Villemoes [this message]
2020-02-28 17:35         ` Tom Rini
2020-02-28 23:09           ` caching BLOBLISTT_SPL_HANDOFF (was Re: [PATCH] common/board_f.c: use #ifdefs a little more consistently) Rasmus Villemoes
2020-03-02 19:47             ` Simon Glass
2020-03-02 20:01               ` caching BLOBLISTT_SPL_HANDOFF Rasmus Villemoes
2020-03-04 23:11                 ` Simon Glass

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=1500fa23-9959-76cc-0b3e-148a22cd46da@prevas.dk \
    --to=rasmus.villemoes@prevas.dk \
    --cc=u-boot@lists.denx.de \
    /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.