[U-Boot] [PATCH v4 0/8] Provide a mechanism to avoid using #ifdef everywhere

Wolfgang Denk wd at denx.de
Sun Nov 10 13:58:38 CET 2013


Dear Simon,

In message <CAPnjgZ3B4sZi_2h2Sw7oop932CcgOu8HO5E_fKmjcyv4wS+eZA at mail.gmail.com> you wrote:
>
...
> > By chance I ran about "include/linux/kconfig.h" in the Linux kernel
> > tree, which provides (among other things) the IS_ENABLED() macro that
> > implements essentially the very same feature.  Using this, the same
> > code would be written as:
> >
> >         if (IS_ENABLED(CONFIG_VERSION_VARIABLE))
> >                 setenv("ver", version_string);  /* set version variable */
...

> Fair enough, sounds reasonable. The relevant kernel code is quite unusual...

Indeed, this code is really a bit creepy...

> Many of U-Boot's options are not just yes/no, so I'm not sure what will
> happen with those. Perhaps they just can't be used with this macro? Part of
> my intent was to allow any option to be used.

I see.  Um... But then, I think the usage of the macro is somewhat
dangerous anyway.

> So for example you can do this:
> 
> struct {
> > const char *str;
> > u_int len;
> > int retry;
> > const char *conf; /* Configuration value */
> > }
> > delaykey [] = {
> > { str: getenv("bootdelaykey"),  retry: 1,
> > conf: autoconf_autoboot_delay_str() },
> > { str: getenv("bootdelaykey2"), retry: 1,
> > conf: autoconf_autoboot_delay_str2() },
> > { str: getenv("bootstopkey"),   retry: 0,
> > conf: autoconf_autoboot_stop_str() },
> > { str: getenv("bootstopkey2"),  retry: 0,
> > conf: autoconf_autoboot_stop_str2() },
> > };

Well, this is not exactly easy to read either.

> or this:
> 
> /* don't retry auto boot? */
> > if (autoconf_boot_retry_time() &&
> >     !delaykey[i].retry)
> > retry_time = -1;
> 
> Note that autoconf_boot_retry_time() will return 0 if the CONFIG is not
> defined, or if its value is 0.

I see what yo mean, but I'd rather clean up the code to avoid such
ambiguities.

> It seems to me we should provide the Linux feature in U-Boot as part of the
> Kconfig stuff, and see where it takes us. Combined with a bit more
> rationalisation of things like main.c it might be enough.

Sounds like a plan - but we don't have to wait; we can add the header
file any time we ike, and start converting pieces of code that seem to
deserve such treatment.  And, probably even more interesting, we can
request it to be used for any new code being added.

> I like the simplicity and power of the autoconf feature, but I have similar
> reservations to others.

I understand you.  Eventuyally ther eis no easy solution that
satisfies all.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Dealing with failure is easy: work hard to improve. Success  is  also
easy  to  handle:  you've  solved  the  wrong  problem.  Work hard to
improve.


More information about the U-Boot mailing list