On Wed, Feb 4, 2026 at 2:45 AM Nathan Chancellor [off-list ref] wrote:

On Wed, Feb 04, 2026 at 11:27:24AM +0800, Icenowy Zheng wrote:

quoted

在 2026-02-04星期三的 11:26 +0800，Icenowy Zheng写道：

quoted

在 2026-02-03星期二的 19:16 -0700，Nathan Chancellor写道：

quoted

+ Rob, Saravana, and devicetree@ since this concerns files they
own.

On Sun, Feb 01, 2026 at 09:02:59PM +0800, Icenowy Zheng wrote:

quoted

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.

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.

Rob