linux-kernel - Re: [PATCH 4/4] kbuild: allow 'make dtbs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 17 Jan 2024 09:37:08 -0600
From: Rob Herring <robh@...nel.org>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: linux-kbuild@...r.kernel.org, devicetree@...r.kernel.org,
	Simon Glass <sjg@...omium.org>, Jonathan Corbet <corbet@....net>,
	Nathan Chancellor <nathan@...nel.org>,
	Nick Desaulniers <ndesaulniers@...gle.com>,
	Nicolas Schier <nicolas@...sle.eu>, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/4] kbuild: allow 'make dtbs_install' to install
 primitive DTBs

On Tue, Jan 09, 2024 at 09:07:37PM +0900, Masahiro Yamada wrote:
> Commit 15d16d6dadf6 ("kbuild: Add generic rule to apply fdtoverlay")
> introduced the -dtbs syntax to apply overlays during the build process.
> 
> However, scripts/Makefile.dtbinst is not aware of the -dtbs syntax,
> so 'make dtbs_install' installs the files directly added to dtb-y.
> (Presumably, it was intentional.)

Yes. The intent was the Makefile should define what's installed or not. 
There's 2 reasons to apply overlays in the build. The first is so a DTB 
can be refactored into a base plus overlay(s) and we keep the original 
full DTB. The second is to test that overlays actually apply because 
testing that at boot time in bootloader is a poor experience and we 
don't want overlays which don't apply to upstream DTs.

Whatever targets you want installed put in dtb-y. Whatever targets are 
just for testing, put in dtb-. The latter are then enabled with 
CONFIG_OF_ALL_DTBS.

> For example, consider this case:
> 
>     foo1-dtbs := foo_base.dtb foo_overlay1.dtbo
>     foo2-dtbs := foo_base.dtb foo_overlay2.dtbo
>     dtb-y := foo1.dtb foo2.dtb
> 
> 'make dtbs_install' only installs foo1.dtb and foo2.dtb. It is suitable
> when the boot image supports a single hardware configuration, or when
> the boot loader in use does not support applying overlays.
> 
> However, when creating a boot image with multiple board supports, it
> wastes storage space, as foo1.dtb and foo2.dtb have foo_base.dtb in
> common.
> 
> From a space perspective, a more optimal solution is to install
> foo_base.dtb, foo_overlay1.dtbo, and foo_overlay2.dtbo, then assemble
> the final dtb (either foo1.dtb or foo2.dtb) on the boot loader.
> 
> This commit adds a new flag, INSTALL_DTBS_PRIMITIVE.
> 
> With INSTALL_DTBS_PRIMITIVE=1, 'make dtbs_install' will install primitive
> files (such as foo_base.dtb, foo_overlay1.dtbo, and foo_overlay2.dtbo in
> this case).

And not install foo1.dtb and foo2.dtb, right? What if one wants to 
install everything? Seems like this needs to be a 3-way option.

I'm not really convinced we need this in the first place though.

> 
> Without INSTALL_DTBS_PRIMITIVE, the current behavior is maintained
> (foo1.dtb and foo2.dtb will be installed in this case).