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
