[PATCH v5 02/29] kconfig: Add tools support to CONFIG_IS_ENABLED()

[Simon Glass]

Hi Masahiro,

On Mon, 27 Sept 2021 at 10:51, Masahiro Yamada <masahiroy at kernel.org> wrote:
>
> On Tue, Sep 28, 2021 at 1:11 AM Alex G. <mr.nuke.me at gmail.com> wrote:
> >
> >
> >
> > On 9/25/21 8:43 PM, Simon Glass wrote:
> > > At present we must separately test for the host build for many options,
> > > since we force them to be enabled. For example, CONFIG_FIT is always
> > > enabled in the host tools, even if CONFIG_FIT is not enabled by the
> > > board itself.
> > >
> > > It would be more convenient if we could use, for example,
> > > CONFIG_IS_ENABLED(FIT) and get CONFIG_HOST_FIT, when building for the
> > > host. Add support for this.
> > >
> > > With this and the tools_build() function, we should be able to remove all
> > > the #ifdefs currently needed in code that is build by tools and targets.
> > >
> > > This will be even nicer when we move to using CONFIG(xxx) everywhere,
> > > since all the #ifdef and IS_ENABLED/CONFIG_IS_ENABLED stuff will go away.
> > >
> > > Signed-off-by: Simon Glass <sjg at chromium.org>
> > > Suggested-by: Rasmus Villemoes <rasmus.villemoes at prevas.dk> # b4f73886
> > > ---
> >
> > In my vision, the host tools are target-agostic. They always support the
> > same feature set: all features. From that point of view, it doesn't make
> > sense to have options which enable or disable tools features.
>
>
> Agree.
> Host tools should not depend on any CONFIG option.

Agreed, although arguably that is not quite what is happening here, We
need some way for shared code to work, so the options are:

if (tools_build() || CONFIG_IS_ENABLED(FIT_SIGNATURE))

or:

if (CONFIG_IS_ENABLED(FIT_SIGNATURE))

I believe the second is better.

BTW we do have a series to drop IS_ENABLED() and CONFIG_IS_ENABLED()
and move to just CONFIG() so it would be:

if (CONFIG(FIT_SIGNATURE))

>
> In Linux kernel, most host tools are target-agnostic.
> (It is true there are some exceptions such as objtool,
> modpost, etc. but in theory we can make all of them
> target-agnostic)
>
> In fact, U-Boot made much more tools target-dependent.
> They must be rebuilt every time you change the configuration.

Can you give some examples? We have tried for the exact opposite of
that and should fix any instances we find.

>
> For example, mkimage in U-Boot supports many boards
> and depends on the configuration.
> It makes less sense to support all sort of board-specific
> firmware in a huge single host tool.

Maybe, but I would much prefer that there is one mkimage that supports
everything.

>
>
> In contrast, Barebox splits it into small programs,
> zynq_mkimage, socfpga_mkimage, etc.,
> each of which is target-agnostic.  [1]
> Makefile decides only whether each program should be built or not.
>
> [1] https://github.com/saschahauer/barebox/blob/v2021.07.0/scripts/Makefile#L22

How does it share code between boards and tools which includes CONFIG options?

Regards,
Simon
[..]