linux-kernel - Re: [PATCH] kbuild: install-extmod-build: do not exclude scripts/dtc/libfdt/

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] [day] [month] [year] [list]

Message-ID: <20260204181356.GA2132823@ax162>
Date: Wed, 4 Feb 2026 11:13:56 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Rob Herring <robh@...nel.org>
Cc: Icenowy Zheng <uwu@...nowy.me>, Nicolas Schier <nsc@...nel.org>,
	Masahiro Yamada <masahiroy@...nel.org>,
	Abel Vesa <abelvesa@...nel.org>, Mingcong Bai <jeffbai@...c.io>,
	WangYuli <wangyuli@...ontech.com>,
	Inochi Amaoto <inochiama@...il.com>,
	James Le Cuirot <chewi@...too.org>, linux-kbuild@...r.kernel.org,
	linux-kernel@...r.kernel.org, Rong Zhang <i@...g.moe>,
	Saravana Kannan <saravanak@...nel.org>, devicetree@...r.kernel.org
Subject: Re: [PATCH] kbuild: install-extmod-build: do not exclude
 scripts/dtc/libfdt/

On Wed, Feb 04, 2026 at 07:31:57AM -0600, Rob Herring wrote:
> On Wed, Feb 4, 2026 at 2:45 AM Nathan Chancellor <nathan@...nel.org> wrote:
> > Ah, thanks for that information. Moving the libfdt.h bits out of
> > bootinfo.h does not seem like it would be too difficult but I am less
> > sure about asm/machine.h. Alternatively, maybe this could be avoided by
> > separating out what you would need from bootinfo.h into its own header
> > but I did not look too hard.
> 
> There shouldn't be that many locations using libfdt functions. Add the
> header where it is used. IWYU
> 
> > As for a solution within install-extmod-build, maybe the libfdt headers
> > could be included so that inadvertent inclusions of libfdt.h do not
> > break the build but the link fails if the module actually tries to use
> > any libfdt functions?
> 
> You do this and then we get to keep the work-around forever as no one
> will care. MIPS is a mess that needs to be cleaned up.

Yeah, that is a valid perspective, I won't push that further. Thanks for
chiming in.

Cheers,
Nathan