Message ID | CAK7LNAQzEHv7Y69xFTPDEhyMP6JX4ghb96UMqMdxYyVyah6-VA@mail.gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [GIT,PULL,1/4] Kbuild updates for v4.21 | expand |
The pull request you sent on Sat, 29 Dec 2018 00:58:38 +0900:
> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git tags/kbuild-v4.21
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/668c35f69cc750aaf07bd5fe7710a47e2aed6e43
Thank you!
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
Hi Linus. > 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. Not exactly what you ask for - but we have make V=2 Example: $ touch include/uapi/linux/elf-em.h $ make V=2 CALL scripts/checksyscalls.sh - due to target missing DESCEND objtool CC init/main.o - due to: include/uapi/linux/elf-em.h CHK include/generated/compile.h CC init/version.o - due to: include/uapi/linux/elf-em.h CC init/do_mounts.o - due to: include/uapi/linux/elf-em.h CC init/do_mounts_initrd.o - due to: include/uapi/linux/elf-em.h CC init/do_mounts_md.o - due to: include/uapi/linux/elf-em.h ... With V=2 kbuild will try to tell you why a target is rebuild. This can sometimes be useful. Here kbuild will tell you: - due to: include/uapi/linux/elf-em.h Which may be a good clue. But you need to figure out yourself why a certain file depends on include/uapi/linux/elf-em.h One way is to look at the .cmd file for a target: $ cat init/.do_mounts_md.o.cmd ... include/linux/module.h \ $(wildcard include/config/modules/tree/lookup.h) \ $(wildcard include/config/module/sig.h) \ $(wildcard include/config/module/unload.h) \ $(wildcard include/config/constructors.h) \ $(wildcard include/config/function/error/injection.h) \ include/linux/kmod.h \ include/linux/umh.h \ include/linux/elf.h \ arch/x86/include/asm/elf.h \ arch/x86/include/asm/user.h \ arch/x86/include/asm/user_64.h \ arch/x86/include/asm/fsgsbase.h \ arch/x86/include/asm/msr-index.h \ arch/x86/include/asm/vdso.h \ $(wildcard include/config/x86/x32.h) \ include/uapi/linux/elf.h \ include/uapi/linux/elf-em.h \ ... In the above all the $(wildcard ...) is the CONFIG_ symbols in the files that trigger a possible dependency on a file representing the CONFIG_ symbol. We can see that the target depends on elf-em.h and if we follow it back we end up with module.h included from do_mounts_md.c Sam
On Sat, Jan 5, 2019 at 12:39 PM Sam Ravnborg <sam@ravnborg.org> wrote: > > Not exactly what you ask for - but we have make V=2 Yeah, that's certainly more convenient than "make --debug". That said, I was more thinking of not any particular "oh, it's recompiling everything" situation (by then it's too late, obviously), but if somebody has been looking at tools for finding and maybe breaking some of our deeper include chains. I know it has come up before (the x86 people did the <linux/schedule.h> split some years ago) and then it was all manual. But I was kind of hoping that maybe some of the kbuild people had looked at this? Linus
Hi Linus, On Sun, Jan 6, 2019 at 5:44 AM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Sat, Jan 5, 2019 at 12:39 PM Sam Ravnborg <sam@ravnborg.org> wrote: > > > > Not exactly what you ask for - but we have make V=2 > > Yeah, that's certainly more convenient than "make --debug". > > That said, I was more thinking of not any particular "oh, it's > recompiling everything" situation (by then it's too late, obviously), > but if somebody has been looking at tools for finding and maybe > breaking some of our deeper include chains. > > I know it has come up before (the x86 people did the > <linux/schedule.h> split some years ago) and then it was all manual. > But I was kind of hoping that maybe some of the kbuild people had > looked at this? Sorry, I do not know more information than Sam provided. I got rid of some unneeded header inclusions in the past, but my work was also manual.