From: Nathan Chancellor <nathan@kernel.org>
To: Icenowy Zheng <uwu@icenowy.me>
Cc: Nicolas Schier <nsc@kernel.org>,
Masahiro Yamada <masahiroy@kernel.org>,
Abel Vesa <abelvesa@kernel.org>, Mingcong Bai <jeffbai@aosc.io>,
WangYuli <wangyuli@uniontech.com>,
Inochi Amaoto <inochiama@gmail.com>,
James Le Cuirot <chewi@gentoo.org>,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
Rong Zhang <i@rong.moe>, Rob Herring <robh@kernel.org>,
Saravana Kannan <saravanak@kernel.org>,
devicetree@vger.kernel.org
Subject: Re: [PATCH] kbuild: install-extmod-build: do not exclude scripts/dtc/libfdt/
Date: Wed, 4 Feb 2026 01:45:17 -0700 [thread overview]
Message-ID: <20260204084517.GA3900164@ax162> (raw)
In-Reply-To: <ed9cd9a5d1f51b83c46ada7adb942e611c0c8a41.camel@icenowy.me>
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@iscas.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
next prev parent reply other threads:[~2026-02-04 8:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260201130259.2906768-1-zhengxingda@iscas.ac.cn>
2026-02-04 2:16 ` [PATCH] kbuild: install-extmod-build: do not exclude scripts/dtc/libfdt/ Nathan Chancellor
2026-02-04 2:56 ` Rob Herring
2026-02-04 3:26 ` Icenowy Zheng
2026-02-04 3:27 ` Icenowy Zheng
2026-02-04 8:45 ` Nathan Chancellor [this message]
2026-02-04 8:46 ` Nathan Chancellor
2026-02-04 13:31 ` Rob Herring
2026-02-04 18:13 ` Nathan Chancellor
2026-02-05 8:22 ` Icenowy Zheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260204084517.GA3900164@ax162 \
--to=nathan@kernel.org \
--cc=abelvesa@kernel.org \
--cc=chewi@gentoo.org \
--cc=devicetree@vger.kernel.org \
--cc=i@rong.moe \
--cc=inochiama@gmail.com \
--cc=jeffbai@aosc.io \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=nsc@kernel.org \
--cc=robh@kernel.org \
--cc=saravanak@kernel.org \
--cc=uwu@icenowy.me \
--cc=wangyuli@uniontech.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox