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

From: Tom Rini <trini@konsulko.com>
To: Simon Glass <sjg@chromium.org>
Cc: U-Boot Mailing List <u-boot@lists.denx.de>,
	Alexandru Gagniuc <mr.nuke.me@gmail.com>,
	Andre Przywara <andre.przywara@arm.com>,
	Rasmus Villemoes <rasmus.villemoes@prevas.dk>,
	Robert Marko <robert.marko@sartura.hr>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Masahiro Yamada <yamada.masahiro@socionext.com>
Subject: Re: [PATCH v5 02/29] kconfig: Add tools support to CONFIG_IS_ENABLED()
Date: Thu, 7 Oct 2021 09:42:09 -0400	[thread overview]
Message-ID: <20211007134209.GS31748@bill-the-cat> (raw)
In-Reply-To: <CAPnjgZ0-tNodY0eqj5jU5dvcvEaUqOQQpbNfWXs9yB=UTmUvhA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2726 bytes --]

On Thu, Oct 07, 2021 at 07:32:04AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 6 Oct 2021 at 20:52, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Oct 06, 2021 at 08:49:13PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Wed, 6 Oct 2021 at 18:26, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Sat, Sep 25, 2021 at 07:43:15PM -0600, 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@chromium.org>
> > > > > Suggested-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> # b4f73886
> > > > > Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
> > > >
> > > > The problem here is we don't include <linux/kconfig.h> automatically
> > > > when building host stuff, I believe.  This is why doing this breaks
> > > > test_mkimage_hashes for me on am335x_evm with:
> > > > /tmp/.bm-work/am335x_evm/tools/mkimage -D -I dts -O dtb -i /tmp/.bm-work/am335x_evm -f /home/trini/work/u-boot/u-boot/test/py/tests/vboot//hash-images.its /tmp/.bm-work/am335x_evm/test.fit
> > > > *** stack smashing detected ***: <unknown> terminated
> > >
> > > Oh dear, and no CI coverage.
> > >
> > > I was reluctant to include kconfig.h everywhere but perhaps that is
> > > the best approach. Will take a look ASAP.
> >
> > Maybe we need to think a bit harder too about how we structure
> > intentionally shared code.
> >
> > Why not, for example, for these common algorithms, rely on typical
> > system headers/libraries in the tooling, which means we validated U-Boot
> > vs common reference, rather than just our implementations?
> 
> Do you mean we use openssl for sha1, for example?

I guess, yes.  Just flat out saying we require openssl for tools, and
doing our best to not make compatibility with libressl difficult, seems
likely to cause less headaches for people than what we already require
in terms of Python.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]