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