On Tue, May 11, 2021 at 07:50:38PM -0500, Alex G. wrote:
> On 5/11/21 5:34 PM, Tom Rini wrote:
> > On Tue, May 11, 2021 at 02:57:03PM -0500, Alex G. wrote:
> > > On 5/6/21 9:24 AM, Simon Glass wrote:
> > > > In preparation for enabling CONFIG_IS_ENABLED() on the host build, add
> > > > some options to enable the various FIT options expected in these tools.
> > > > This will ensure that the code builds correctly when CONFIG_HOST_xxx
> > > > is distinct from CONFIG_xxx.
> > > > 
> > > > Signed-off-by: Simon Glass <s...@chromium.org>
> > > 
> > > Reviewed-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
> > > 
> > > This makes me wonder whether we should just always enable host features.
> > > Right now, each defconfig can have a different mkimage config. So we 
> > > should
> > > really have mkimage-imx8, mkimage-stm32mp, etc, which support different
> > > feature sets. This doesn't make much sense.
> > > 
> > > The alternative is to get rid of all these configs and always enable 
> > > mkimage
> > > features. The disadvantage is that we'd require openssl for building 
> > > target
> > > code.
> > > 
> > > A second alternative is to have a mkimage-nossl that gets built and used
> > > when openssl isn't available. It's really just openssl that causes such a
> > > schism.
> > 
> > It would probably be best to have a single mkimage for everyone, with
> > everything on.  But before then we really need to move from openssl to
> > gnutls or some other library that's compatible as it's been raised
> > before that linking with openssl like we do is a license violation I
> > believe.
> 
> How about the former alternative for now? i.e. compile mkimage with or
> without openssl, and have that be the only host side switch.

That would be a step in the right direction, yeah.

-- 
Tom

Attachment: signature.asc
Description: PGP signature

Reply via email to