Re: [PATCH] kbuild: install-extmod-build: install kernel/kallsyms_internal.h

[Nathan Chancellor <nathan@kernel.org>]

Hi Denis,

On Tue, Oct 06, 2026 at 09:39:51PM +0200, Denis Benato wrote:
> On 10/6/26 10:11, Nathan Chancellor wrote:
> > On Mon, Oct 05, 2026 at 08:01:23PM +0000, Denis Benato wrote:
> >> The tree staged by install-extmod-build contains no kernel/ files, but
> >> since commit 4fafd1165b33 ("kallsyms: increase marker density to 16:1
> >> to accelerate lookups") scripts/kallsyms.c includes
> >> ../kernel/kallsyms_internal.h.
> > You did not add either the author or the committer of 4fafd1165b33, I
> > have done so now. This would need to be handled by them. However...
> 
> Apologies. I used whatever came back from get_maintainers.pl without
> much thinking given this is not the area of kernel I lurk in, but thanks
> for taking care of that.

No worries, that was a little unfair of me to put on you since this is a
bit of a weird situation that most contributors won't run into (a patch
living in one maintainer's tree that needs a follow up in code
maintained by another). A good rule of thumb is if you have bisected to
a particular change, always include the author and committer of said
change in the report, in addition to whatever get_maintainers.pl spits
out :)

> >> install-extmod-build rebuilds the host programs inside the staged tree
> >> whenever CC differs from HOSTCC (cross builds, or a ccache-wrapped CC).
> >> scripts/kallsyms is hostprogs-always-y, so that rebuild fails with:
> >>
> >>   scripts/kallsyms.c:39:10: fatal error: '../kernel/kallsyms_internal.h' file not found
> >>      39 | #include "../kernel/kallsyms_internal.h"
> >>         |          ^~~~~~~
> > I would rather not ship an internal kernel header in the external module
> > build. If these defines are needed to build scripts/kallsyms.c, they
> > should live in a separate header that is included in
> > {kernel,scripts}/kallsyms.c that is safe to expose to the external
> > module build but I defer to the 4fafd1165b33 folks.
> 
> Fair. This is something I spotted compiling our training/testing kernel
> at OGC using the github CI and my main goal was raising awareness
> on this issue so I simply started that by sending whatever glm did
> to make it build ahah.
> 
> Please when something better comes up CC me as well so I can use
> the proper fix rather than this llm-cooked thing :)

Indeed, thanks for the report raising the issue, I hope Andrew and/or
Jim can comment on it soon.

-- 
Cheers,
Nathan