[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260204084517.GA3900164@ax162>
Date: Wed, 4 Feb 2026 01:45:17 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Icenowy Zheng <uwu@...nowy.me>
Cc: 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>,
Rob Herring <robh@...nel.org>,
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 11:27:24AM +0800, Icenowy Zheng wrote:
> 在 2026-02-04星期三的 11:26 +0800,Icenowy Zheng写道:
> > 在 2026-02-03星期二的 19:16 -0700,Nathan Chancellor写道:
> > > + Rob, Saravana, and devicetree@ since this concerns files they
> > > own.
> > >
> > > On Sun, Feb 01, 2026 at 09:02:59PM +0800, Icenowy Zheng wrote:
> > > > There exists a header file in include/linux/ called libfdt.h that
> > > > is
> > > > just a wrapper for libfdt header file in scripts/dtc/libfdt/.
> > > > This
> > > > makes
> > > > the headers inside libfdt copy at scripts/dtc/libfdt/ part of the
> > > > kernel
> > > > headers for building external modules.
> > > >
> > > > Do not exclude them, otherwise modules that include
> > > > <linux/libfdt.h>
> > > > will fail to build externally.
> > > >
> > > > Fixes: aaed5c7739be ("kbuild: slim down package for building
> > > > external modules")
> > > > Signed-off-by: Icenowy Zheng <zhengxingda@...as.ac.cn>
> > >
> > > This does indeed bring back scripts/dtc/libfdt back into the
> > > headers
> > > package that I examined. However, how does including libfdt.h in an
> > > external module actually work, even with this change? libfdt
> > > appears
> > > to
> > > be built into vmlinux IIUC and I do not see any EXPORT_SYMBOLs in
> > > the
> > > list, so how can you actually use any of the functions from libfdt
> > > within the module? Would you just build and link the pieces that
> > > your
> > > module needs using the other source files?
> >
> > To be honest what I met is quite weird -- my module [1] does not use
> > libfdt at all. However, as a MIPS platform-specific module, it
> > includes
> > arch/mips/include/asm/bootinfo.h, which pulls in libfdt.h.
> >
> > Or maybe I should prevent libfdt.h inclusion from other kernel
> > headers?
> > It looks like only two headers in MIPS architecture-specific code
> > includes libfdt.h, asm/bootinfo.h and asm/machine.h .
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.
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?
> Ah, forgot to place the [1] reference link, although I doubt whether
> it's really related to the context:
>
> [1] https://github.com/Icenowy/mips-loong-3nod-laptop-driver
This was helpful for testing the following diff, so thanks for providing
it still.
Cheers,
Nathan
Powered by blists - more mailing lists