[PATCH v4 1/4] tools: Separate image types which depend on OpenSSL

[Andre Przywara]

On Fri, 22 Oct 2021 11:09:27 -0400
Tom Rini <trini at konsulko.com> wrote:

Hi,

> On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Behún wrote:
> > On Fri, 22 Oct 2021 12:09:19 +0200
> > Heinrich Schuchardt <heinrich.schuchardt at canonical.com> wrote:
> >   
> > > On 10/21/21 15:00, Marek Behún wrote:  
> > > > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for mvebu
> > > > platform in Kconfig?
> > > >     
> > > 
> > > We should only use 'imply' for suggested settings and never for hard 
> > > requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying it 
> > > for mvebu would be redundant.
> > > 
> > > In an OS distribution we only want to ship a single version of mkimage. 
> > > So it is good to elimate symbol CONFIG_MXS.
> > > 
> > > How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO.
> > > 
> > > Tom wrote regarding this aspect in 
> > > https://lists.denx.de/pipermail/u-boot/2021-September/460251.html:
> > > 
> > > "if we're building a generically useful tool, we don't want another
> > > symbol for it."  
> > 
> > OK, so mkimage and dumpimage should be always generic and always
> > support all platforms, that makes sense, since the tools can be
> > installed as a distribution package.
> > 
> > But I still think it should be possible to cripple these tools if the
> > developer wants to disable libcrypto due to embedded environment.  

Well, I don't think this is the real question here, is it?
I think the tools part is clear: distros want to build just mkimage,
supporting as many platforms as possible, and might need to avoid OpenSSL.
This should be covered by TOOLS_LIBCRYPTO=[yn] and "make
tools-only_defconfg && make tools", and Samuel's patch actually fixes the
build (at least somewhat, I still get link errors).

The question at hand is whether *board* builds should be able to *force*
TOOLS_LIBCRYPTO, aka "select" this symbol. This was somewhat denied by
Alex, on the grounds of the top comment in tools/Makefile:
# Host tools can be used across multiple targets, or different configurations
# of the same target. Thus, host tools must be able to handle any combination
# of target configurations. To prevent having different variations of the same
# tool, the tool build options may not depend on target configuration.

I read this as: "a tool like mkimage should not use #ifdef
CONFIG_PLATFORM_FEATURE", but I don't see why a defconfig should not be
able to select TOOLS_LIBCRYPTO, if that's needed to package the firmware.

Do I get this correctly? If that's the case, then I think we should
actually stick more with the solution in v2, or maybe split that patch, so
v4 plus Pali's separate patch to select/depend on LIBCRYPTO for boards
using kwbimage.

Does that make sense?

Cheers,
Andre

> 
> This is probably the time to reach out to some of the distro folks to
> see how they would like to see things handled for "build the tools we
> need to package for the user" and also "build the binary for the
> platform".
>