On Fri, 22 Oct 2021 11:09:27 -0400 Tom Rini trini@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@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".