Re: [GIT PULL 1/4] Kbuild updates for v4.21

[Linus Torvalds]

Masahiro,
 this isn't really related to the your request, but to just another
pull request that caused much more of a rebuild than I expected.

Doing a "make --debug", I see that the cause was that it touched
include/uapi/linux/elf-em.h, and make says things like

     Prerequisite 'include/uapi/linux/elf-em.h' is newer than target
'drivers/net/ethernet/sfc/falcon/efx.o'.
    Must remake target 'drivers/net/ethernet/sfc/falcon/efx.o'.

which is obviously true, but was unexpected.

The chain seems to be

  <linux/module.h> ->
    <linux/elf.h> ->
      <uapi/linux/elf.h> ->
        <linux/elf-em.h>

or similar, and the reason <linux/module.h> does that is it wants some
of the elf types (ie code like this:

struct mod_kallsyms {
        Elf_Sym *symtab;
        unsigned int num_symtab;
        char *strtab;
};

and for declarations of module_bug_finalize() etc.

Fine, fine. I can see why everybody includes <linux/module.h>, and I
can see why module.h in turn wants the elf information.

And I think I can see a way to avoid this chain, particularly with
lots of those things really being internal to kernel/module.h and
shouldn't be visible to random <linux/module.h> users.

But the reason for this email to you is simply to ask whether you
use/have any tools for seeing these kinds of deep include chains.
Getting rid of some of the deep chains of header includes would likely
speed up kernel builds even when a rebuild is forced, and when it's
something like "we really shouldn't have rebuilt that file at all" the
speedup is obviously even bigger than just a "the compiler saw much
too much unnecessary header contents".

                 Linus