Re: [PATCH 15/23] modpost: emit module descriptors as assembly

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Wed, Sep 09, 2026 at 07:59:55AM -0700, Linus Torvalds wrote:
> On Tue, 8 Sept 2026 at 13:58, Lorenzo Stoakes (ARM) <ljs@kernel.org> wrote:
> >
> > modpost generates a descriptor for every module in the form of a
> > <module>.mod.c file with .modinfo strings, the __this_module descriptor,
> > exported symbol tables and (with CONFIG_MODVERSIONS set), the CRC of
> > imported symbols.
> >
> > These files are compiled like any other kernel C file with all of the
> > -include preamble, as well as including linux/module.h, header dependencies
> > generated by fixdep of a few hundred headers, an objtool run and if LTO is
> > being performed, a link is performed to generate native code.
>
> This kind of triggers the same reaction as the kallsyms code: I think
> not including <linux/module.h> is probably the biggest win in this
> all, and precomputing the offsets of the (few) structures that modpost
> uses then makes the whole end result fairly trivial in raw asm.

Right indeed :)

>
> Fine.
>
> BUT.
>
> You end up with things like this instead:
>
> > diff --git a/scripts/mod/module-offsets.c b/scripts/mod/module-offsets.c
>
> where it generates a header file for those asm scripts so that the asm
> generation can do things like
>
>         buf_printf(buf, "\t.size __this_module, %d\n",
> MOD_SIZEOF_struct_module);
>
> etc.
>
> But I - again - get the feeling that this is all going through AS as a
> silly way to generate an object file, and that there really isn't any
> obvious advantage to that side quest.

Well it seems the biggest advantage in doing assembly over directly
manipulating an object file is that you avoid any arch-specific nonsense,
as with kallsyms.

>
> Becuase no human ever wants to see that asm file, and it's no more
> legible than generating the object file directly would have been.
>
> So I get the feeling that it would again be more natural to just
> generate the object file directly when all those files really end up
> being are a few symbol definitions and a couple of fixed structures
> (is there anything but the magic "__this_module" thing and the modinfo
> unique ID thing?)
>
> And again - I feel like nobody sane would want to write that code. I
> certainly don't. But if this was at least partly automated anyway,
> going that extra step might not be all that horrific.
>
> I'll also be honest: part of why I do these suggestions is that I do
> think it would be faster to skip the intermediate assembler step, but
> a big part of it is that I don't love the random turds our build
> creates. Getting rid of the *.mod.c files would be a cleanup of our
> strange build.

Well the *.mod.c turds are flushed already, but replaced with smaller
*.mod.S ones instead :)

The LLM says the time taken per assembler step is ~7.5ms per .mod.S which
is .65s of wall time on the threadripper so it terms of a build it's into
the noise territory at least for a bigger box (plus obviously you won't go
to _zero_ cost by writing the object file directly).

Overall I think it's not _currently_ worth it as part of this work, but
it's something I can set the LLM on as a follow-up maybe? Could do a
'eliminate build artifacts' pass in general.


>
>              Linus

--
Cheers, Lorenzo