lkml.org 
[lkml]   [2019]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [GIT PULL 1/4] Kbuild updates for v4.21
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

\
 
 \ /
  Last update: 2019-01-05 19:37    [W:0.056 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site