From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 01A4AC433F5 for ; Fri, 22 Oct 2021 15:56:23 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 417AF60F6E for ; Fri, 22 Oct 2021 15:56:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 417AF60F6E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 746DE834C1; Fri, 22 Oct 2021 17:56:20 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id DF3FA8326F; Fri, 22 Oct 2021 17:56:17 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by phobos.denx.de (Postfix) with ESMTP id 6ABD2834C1 for ; Fri, 22 Oct 2021 17:56:14 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=andre.przywara@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 657CC1FB; Fri, 22 Oct 2021 08:56:13 -0700 (PDT) Received: from donnerap.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9295F3F70D; Fri, 22 Oct 2021 08:56:11 -0700 (PDT) Date: Fri, 22 Oct 2021 16:56:09 +0100 From: Andre Przywara To: Tom Rini Cc: Marek =?UTF-8?B?QmVow7pu?= , Vagrant Cascadian , Peter Robinson , Matthias Brugger , Heinrich Schuchardt , Samuel Holland , Pali =?UTF-8?B?Um9ow6Fy?= , u-boot@lists.denx.de, Jagan Teki , "Alex G ." , Artem Lapkin , Priyanka Jain , Sughosh Ganu Subject: Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL Message-ID: <20211022165609.1725e93b@donnerap.cambridge.arm.com> In-Reply-To: <20211022150927.GJ3577824@bill-the-cat> References: <20211020024455.48136-1-samuel@sholland.org> <20211020024455.48136-2-samuel@sholland.org> <20211020072925.drf6622qhq4yykg6@pali> <20211020142902.12219c45@donnerap.cambridge.arm.com> <20211020134752.62k4fxukucj5rodh@pali> <20211021150048.59bb90d6@thinkpad> <20211022165922.22164ef8@thinkpad> <20211022150927.GJ3577824@bill-the-cat> Organization: ARM X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; aarch64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On Fri, 22 Oct 2021 11:09:27 -0400 Tom Rini wrote: Hi, > On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Beh=C3=BAn wrote: > > On Fri, 22 Oct 2021 12:09:19 +0200 > > Heinrich Schuchardt wrote: > > =20 > > > On 10/21/21 15:00, Marek Beh=C3=BAn wrote: =20 > > > > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for mvebu > > > > platform in Kconfig? > > > > =20 > > >=20 > > > We should only use 'imply' for suggested settings and never for hard= =20 > > > requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying it= =20 > > > for mvebu would be redundant. > > >=20 > > > In an OS distribution we only want to ship a single version of mkimag= e.=20 > > > So it is good to elimate symbol CONFIG_MXS. > > >=20 > > > How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO. > > >=20 > > > Tom wrote regarding this aspect in=20 > > > https://lists.denx.de/pipermail/u-boot/2021-September/460251.html: > > >=20 > > > "if we're building a generically useful tool, we don't want another > > > symbol for it." =20 > >=20 > > 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. > >=20 > > But I still think it should be possible to cripple these tools if the > > developer wants to disable libcrypto due to embedded environment. =20 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=3D[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 configuratio= ns # of the same target. Thus, host tools must be able to handle any combinati= on # of target configurations. To prevent having different variations of the s= ame # 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 >=20 > 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". >=20