Re: [PATCH] kbuild: install-extmod-build: install kernel/kallsyms_internal.h
From: jim . cromie
Date: Thu Oct 08 2026 - 18:43:26 EST
On Thu, Oct 8, 2026 at 10:47 AM Nathan Chancellor <nathan@xxxxxxxxxx> wrote:
>
> 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.
>
The easiest fix is to just copy the 3 macro defs over to scripts/kallsyms.c,
with a suitably explicit msg about the coupling.
Andrew, do you want it as a fixup ?
> --
> Cheers,
> Nathan