kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-09-28 19:20:30 +00:00
Code Issues Releases Packages Activity
linux/scripts/basic/fixdep.c

365 lines
9.1 KiB
Raw Permalink Normal View History

Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kbuild: move autoconf.h to include/generated Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Michal Marek <mmarek@suse.cz>
2009-10-18 00:49:24 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kbuild: move autoconf.h to include/generated Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Michal Marek <mmarek@suse.cz>
2009-10-18 00:49:24 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kbuild: move autoconf.h to include/generated Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Michal Marek <mmarek@suse.cz>
2009-10-18 00:49:24 +02:00
fixdep: trivial: typo fix and correction Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-08-08 21:20:50 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] kbuild: fix dependency generation Commit 2e3646e51b2d6415549b310655df63e7e0d7a080 changed the way the split config tree is built, but failed to also adjust fixdep accordingly - if changing a config option from or to m, files referencing the respective CONFIG_..._MODULE (but not the corresponding CONFIG_...) didn't get rebuilt. The problem is that trisate symbol are represent with three different symbols: SYMBOL=n => no symbol defined SYMBOL=y => CONFIG_SYMBOL defined to '1' SYMBOL=m => CONFIG_SYMBOL_MODULE defined to '1' But conf_split_config do not distingush between the =y and =m case, so only the =y case is honoured. This is fixed in fixdep so when a CONFIG symbol with _MODULE is found we skip that part and only look for the CONFIG_SYMBOL version. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-03-29 10:27:14 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kbuild: redo fake deps at include/config/*.h Make include/config/foo/bar.h fake deps files generation simpler. * delete .h suffix those aren't header files, shorten filenames, * delete tolower() Linux filesystems can deal with both upper and lowercase filenames very well, * put everything in 1 directory Presumably 'mkdir -p' split is from dark times when filesystems handled huge directories badly, disks were round adding to seek times. x86_64 allmodconfig lists 12364 files in include/config. ../obj/include/config/ ├── 104_QUAD_8 ├── 60XX_WDT ├── 64BIT ... ├── ZSWAP_DEFAULT_ON ├── ZSWAP_ZPOOL_DEFAULT └── ZSWAP_ZPOOL_DEFAULT_ZBUD 0 directories, 12364 files Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-04-15 20:36:07 +03:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kbuild: move autoconf.h to include/generated Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Michal Marek <mmarek@suse.cz>
2009-10-18 00:49:24 +02:00
kbuild: redo fake deps at include/config/*.h Make include/config/foo/bar.h fake deps files generation simpler. * delete .h suffix those aren't header files, shorten filenames, * delete tolower() Linux filesystems can deal with both upper and lowercase filenames very well, * put everything in 1 directory Presumably 'mkdir -p' split is from dark times when filesystems handled huge directories badly, disks were round adding to seek times. x86_64 allmodconfig lists 12364 files in include/config. ../obj/include/config/ ├── 104_QUAD_8 ├── 60XX_WDT ├── 64BIT ... ├── ZSWAP_DEFAULT_ON ├── ZSWAP_ZPOOL_DEFAULT └── ZSWAP_ZPOOL_DEFAULT_ZBUD 0 directories, 12364 files Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-04-15 20:36:07 +03:00
fixdep: trivial: typo fix and correction Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-08-08 21:20:50 +08:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: faster CONFIG_ search Do you think kernel build is 100% dominated by gcc? You are wrong! One small utility called "fixdep" consistently manages to sneak into profile's first page (unless you have small monitor of course). The choke point is this clever code: for (; m < end; m++) { if (*m == INT_CONF) { p = (char *) m ; goto conf; } if (*m == INT_ONFI) { p = (char *) m-1; goto conf; } if (*m == INT_NFIG) { p = (char *) m-2; goto conf; } if (*m == INT_FIG_) { p = (char *) m-3; goto conf; } 4 branches per 4 characters is not fast. Use strstr(3), so that SSE2 etc can be used. With this patch, fixdep is so deep at the bottom, it is hard to find it. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-08-24 21:03:05 +03:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: check return value of printf() and putchar() When there is not enough space on your storage device, the build will fail with 'No space left on device' error message. The reason is obvious from the message, so you will free up some disk space, then you will resume the build. However, sometimes you may still see a mysterious error message: unterminated call to function 'wildcard': missing ')'. If you run out of the disk space, fixdep may end up with generating incomplete .*.cmd files. For example, if the disk-full error occurs while fixdep is running print_dep(), the .*.cmd might be truncated like this: $(wildcard include/config/ When you run 'make' next time, this broken .*.cmd will be included, then Make will terminate parsing since it is a wrong syntax. Once this happens, you need to run 'make clean' or delete the broken .*.cmd file manually. Even if you do not see any error message, the .*.cmd files after any error could be potentially incomplete, and unreliable. You may miss the re-compilation due to missing header dependency. If printf() cannot output the string for disk shortage or whatever reason, it returns a negative value, but currently fixdep does not check it at all. Consequently, fixdep *successfully* generates a broken .*.cmd file. Make never notices that since fixdep exits with 0, which means success. Given the intended usage of fixdep, it must respect the return value of not only malloc(), but also printf() and putchar(). This seems a long-standing issue since the introduction of fixdep. In old days, Kbuild tried to provide an extra safety by letting fixdep output to a temporary file and renaming it after everything is done: scripts/basic/fixdep $(depfile) $@ '$(make-cmd)' > $(dot-target).tmp;\ rm -f $(depfile); \ mv -f $(dot-target).tmp $(dot-target).cmd) It was no help to avoid the current issue; fixdep successfully created a truncated tmp file, which would be renamed to a .*.cmd file. This problem should be fixed by propagating the error status to the build system because: [1] Since commit 9c2af1c7377a ("kbuild: add .DELETE_ON_ERROR special target"), Make will delete the target automatically on any failure in the recipe. [2] Since commit 392885ee82d3 ("kbuild: let fixdep directly write to .*.cmd files"), .*.cmd file is included only when the corresponding target already exists. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-06-25 15:54:19 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kbuild: add static to prototypes Warnings found via gcc -Wmissing-prototypes. Signed-off-by: Trevor Keith <tsrk@tsrk.net> Acked-by: WANG Cong <xiyou.wangcong@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2009-09-18 12:49:23 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kbuild: simplify dependency generation for CONFIG_TRIM_UNUSED_KSYMS My main motivation of this commit is to clean up scripts/Kbuild.include and scripts/Makefile.build. Currently, CONFIG_TRIM_UNUSED_KSYMS works with a tricky gimmick; possibly exported symbols are detected by letting $(CPP) replace EXPORT_SYMBOL* with a special string '=== __KSYM_*===', which is post-processed by sed, and passed to fixdep. The extra preprocessing is costly, and hacking cmd_and_fixdep is ugly. I came up with a new way to find exported symbols; insert a dummy symbol __ksym_marker_* to each potentially exported symbol. Those dummy symbols are picked up by $(NM), post-processed by sed, then appended to .*.cmd files. I collected the post-process part to a new shell script scripts/gen_ksymdeps.sh for readability. The dummy symbols are put into the .discard.* section so that the linker script rips them off the final vmlinux or modules. A nice side-effect is building with CONFIG_TRIM_UNUSED_KSYMS will be much faster. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Nicolas Pitre <nico@linaro.org>
2018-11-30 10:05:26 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: use hash table instead of a single array I noticed fixdep uses ~2% of cpu time in kernel build, in function use_config() fixdep spends a lot of cpu cycles in linear searches in its internal string array. With about 400 stored strings per dep file, this begins to be noticeable. Convert fixdep to use a hash table. kbuild results on my x86_64 allmodconfig Before patch : real 10m30.414s user 61m51.456s sys 8m28.200s real 10m12.334s user 61m50.236s sys 8m30.448s real 10m42.947s user 61m50.028s sys 8m32.380s After: real 10m8.180s user 61m22.506s sys 8m32.384s real 10m35.039s user 61m21.654s sys 8m32.212s real 10m14.487s user 61m23.498s sys 8m32.312s Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-11-09 16:29:27 +01:00
modpost,fixdep: Replace zero-length array with flexible-array The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-05-07 13:56:01 -05:00
fixdep: use hash table instead of a single array I noticed fixdep uses ~2% of cpu time in kernel build, in function use_config() fixdep spends a lot of cpu cycles in linear searches in its internal string array. With about 400 stored strings per dep file, this begins to be noticeable. Convert fixdep to use a hash table. kbuild results on my x86_64 allmodconfig Before patch : real 10m30.414s user 61m51.456s sys 8m28.200s real 10m12.334s user 61m50.236s sys 8m30.448s real 10m42.947s user 61m50.028s sys 8m32.380s After: real 10m8.180s user 61m22.506s sys 8m32.384s real 10m35.039s user 61m21.654s sys 8m32.212s real 10m14.487s user 61m23.498s sys 8m32.312s Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-11-09 16:29:27 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: use hash table instead of a single array I noticed fixdep uses ~2% of cpu time in kernel build, in function use_config() fixdep spends a lot of cpu cycles in linear searches in its internal string array. With about 400 stored strings per dep file, this begins to be noticeable. Convert fixdep to use a hash table. kbuild results on my x86_64 allmodconfig Before patch : real 10m30.414s user 61m51.456s sys 8m28.200s real 10m12.334s user 61m50.236s sys 8m30.448s real 10m42.947s user 61m50.028s sys 8m32.380s After: real 10m8.180s user 61m22.506s sys 8m32.384s real 10m35.039s user 61m21.654s sys 8m32.212s real 10m14.487s user 61m23.498s sys 8m32.312s Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-11-09 16:29:27 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: use hash table instead of a single array I noticed fixdep uses ~2% of cpu time in kernel build, in function use_config() fixdep spends a lot of cpu cycles in linear searches in its internal string array. With about 400 stored strings per dep file, this begins to be noticeable. Convert fixdep to use a hash table. kbuild results on my x86_64 allmodconfig Before patch : real 10m30.414s user 61m51.456s sys 8m28.200s real 10m12.334s user 61m50.236s sys 8m30.448s real 10m42.947s user 61m50.028s sys 8m32.380s After: real 10m8.180s user 61m22.506s sys 8m32.384s real 10m35.039s user 61m21.654s sys 8m32.212s real 10m14.487s user 61m23.498s sys 8m32.312s Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-11-09 16:29:27 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: use hash table instead of a single array I noticed fixdep uses ~2% of cpu time in kernel build, in function use_config() fixdep spends a lot of cpu cycles in linear searches in its internal string array. With about 400 stored strings per dep file, this begins to be noticeable. Convert fixdep to use a hash table. kbuild results on my x86_64 allmodconfig Before patch : real 10m30.414s user 61m51.456s sys 8m28.200s real 10m12.334s user 61m50.236s sys 8m30.448s real 10m42.947s user 61m50.028s sys 8m32.380s After: real 10m8.180s user 61m22.506s sys 8m32.384s real 10m35.039s user 61m21.654s sys 8m32.212s real 10m14.487s user 61m23.498s sys 8m32.312s Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-11-09 16:29:27 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: use hash table instead of a single array I noticed fixdep uses ~2% of cpu time in kernel build, in function use_config() fixdep spends a lot of cpu cycles in linear searches in its internal string array. With about 400 stored strings per dep file, this begins to be noticeable. Convert fixdep to use a hash table. kbuild results on my x86_64 allmodconfig Before patch : real 10m30.414s user 61m51.456s sys 8m28.200s real 10m12.334s user 61m50.236s sys 8m30.448s real 10m42.947s user 61m50.028s sys 8m32.380s After: real 10m8.180s user 61m22.506s sys 8m32.384s real 10m35.039s user 61m21.654s sys 8m32.212s real 10m14.487s user 61m23.498s sys 8m32.312s Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-11-09 16:29:27 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: use hash table instead of a single array I noticed fixdep uses ~2% of cpu time in kernel build, in function use_config() fixdep spends a lot of cpu cycles in linear searches in its internal string array. With about 400 stored strings per dep file, this begins to be noticeable. Convert fixdep to use a hash table. kbuild results on my x86_64 allmodconfig Before patch : real 10m30.414s user 61m51.456s sys 8m28.200s real 10m12.334s user 61m50.236s sys 8m30.448s real 10m42.947s user 61m50.028s sys 8m32.380s After: real 10m8.180s user 61m22.506s sys 8m32.384s real 10m35.039s user 61m21.654s sys 8m32.212s real 10m14.487s user 61m23.498s sys 8m32.312s Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-11-09 16:29:27 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: use hash table instead of a single array I noticed fixdep uses ~2% of cpu time in kernel build, in function use_config() fixdep spends a lot of cpu cycles in linear searches in its internal string array. With about 400 stored strings per dep file, this begins to be noticeable. Convert fixdep to use a hash table. kbuild results on my x86_64 allmodconfig Before patch : real 10m30.414s user 61m51.456s sys 8m28.200s real 10m12.334s user 61m50.236s sys 8m30.448s real 10m42.947s user 61m50.028s sys 8m32.380s After: real 10m8.180s user 61m22.506s sys 8m32.384s real 10m35.039s user 61m21.654s sys 8m32.212s real 10m14.487s user 61m23.498s sys 8m32.312s Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-11-09 16:29:27 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: use hash table instead of a single array I noticed fixdep uses ~2% of cpu time in kernel build, in function use_config() fixdep spends a lot of cpu cycles in linear searches in its internal string array. With about 400 stored strings per dep file, this begins to be noticeable. Convert fixdep to use a hash table. kbuild results on my x86_64 allmodconfig Before patch : real 10m30.414s user 61m51.456s sys 8m28.200s real 10m12.334s user 61m50.236s sys 8m30.448s real 10m42.947s user 61m50.028s sys 8m32.380s After: real 10m8.180s user 61m22.506s sys 8m32.384s real 10m35.039s user 61m21.654s sys 8m32.212s real 10m14.487s user 61m23.498s sys 8m32.312s Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-11-09 16:29:27 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: use hash table instead of a single array I noticed fixdep uses ~2% of cpu time in kernel build, in function use_config() fixdep spends a lot of cpu cycles in linear searches in its internal string array. With about 400 stored strings per dep file, this begins to be noticeable. Convert fixdep to use a hash table. kbuild results on my x86_64 allmodconfig Before patch : real 10m30.414s user 61m51.456s sys 8m28.200s real 10m12.334s user 61m50.236s sys 8m30.448s real 10m42.947s user 61m50.028s sys 8m32.380s After: real 10m8.180s user 61m22.506s sys 8m32.384s real 10m35.039s user 61m21.654s sys 8m32.212s real 10m14.487s user 61m23.498s sys 8m32.312s Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-11-09 16:29:27 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: use hash table instead of a single array I noticed fixdep uses ~2% of cpu time in kernel build, in function use_config() fixdep spends a lot of cpu cycles in linear searches in its internal string array. With about 400 stored strings per dep file, this begins to be noticeable. Convert fixdep to use a hash table. kbuild results on my x86_64 allmodconfig Before patch : real 10m30.414s user 61m51.456s sys 8m28.200s real 10m12.334s user 61m50.236s sys 8m30.448s real 10m42.947s user 61m50.028s sys 8m32.380s After: real 10m8.180s user 61m22.506s sys 8m32.384s real 10m35.039s user 61m21.654s sys 8m32.212s real 10m14.487s user 61m23.498s sys 8m32.312s Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-11-09 16:29:27 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: use hash table instead of a single array I noticed fixdep uses ~2% of cpu time in kernel build, in function use_config() fixdep spends a lot of cpu cycles in linear searches in its internal string array. With about 400 stored strings per dep file, this begins to be noticeable. Convert fixdep to use a hash table. kbuild results on my x86_64 allmodconfig Before patch : real 10m30.414s user 61m51.456s sys 8m28.200s real 10m12.334s user 61m50.236s sys 8m30.448s real 10m42.947s user 61m50.028s sys 8m32.380s After: real 10m8.180s user 61m22.506s sys 8m32.384s real 10m35.039s user 61m21.654s sys 8m32.212s real 10m14.487s user 61m23.498s sys 8m32.312s Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-11-09 16:29:27 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: use hash table instead of a single array I noticed fixdep uses ~2% of cpu time in kernel build, in function use_config() fixdep spends a lot of cpu cycles in linear searches in its internal string array. With about 400 stored strings per dep file, this begins to be noticeable. Convert fixdep to use a hash table. kbuild results on my x86_64 allmodconfig Before patch : real 10m30.414s user 61m51.456s sys 8m28.200s real 10m12.334s user 61m50.236s sys 8m30.448s real 10m42.947s user 61m50.028s sys 8m32.380s After: real 10m8.180s user 61m22.506s sys 8m32.384s real 10m35.039s user 61m21.654s sys 8m32.212s real 10m14.487s user 61m23.498s sys 8m32.312s Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-11-09 16:29:27 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: use hash table instead of a single array I noticed fixdep uses ~2% of cpu time in kernel build, in function use_config() fixdep spends a lot of cpu cycles in linear searches in its internal string array. With about 400 stored strings per dep file, this begins to be noticeable. Convert fixdep to use a hash table. kbuild results on my x86_64 allmodconfig Before patch : real 10m30.414s user 61m51.456s sys 8m28.200s real 10m12.334s user 61m50.236s sys 8m30.448s real 10m42.947s user 61m50.028s sys 8m32.380s After: real 10m8.180s user 61m22.506s sys 8m32.384s real 10m35.039s user 61m21.654s sys 8m32.212s real 10m14.487s user 61m23.498s sys 8m32.312s Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-11-09 16:29:27 +01:00
kbuild: redo fake deps at include/config/*.h Make include/config/foo/bar.h fake deps files generation simpler. * delete .h suffix those aren't header files, shorten filenames, * delete tolower() Linux filesystems can deal with both upper and lowercase filenames very well, * put everything in 1 directory Presumably 'mkdir -p' split is from dark times when filesystems handled huge directories badly, disks were round adding to seek times. x86_64 allmodconfig lists 12364 files in include/config. ../obj/include/config/ ├── 104_QUAD_8 ├── 60XX_WDT ├── 64BIT ... ├── ZSWAP_DEFAULT_ON ├── ZSWAP_ZPOOL_DEFAULT └── ZSWAP_ZPOOL_DEFAULT_ZBUD 0 directories, 12364 files Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-04-15 20:36:07 +03:00
fixdep: use fflush() and ferror() to ensure successful write to files Currently, fixdep checks the return value from (v)printf(), but it does not ensure the complete write to the .cmd file. printf() just writes data to the internal buffer, which usually succeeds. (Of course, it may fail for another reason, for example when the file descriptor is closed, but that is another story.) When the buffer (4k?) is full, an actual write occurs, and printf() may really fail. One of typical cases is "No space left on device" when the disk is full. The data remaining in the buffer will be pushed out to the file when the program exits, but we never know if it is successful. One straight-forward fix would be to add the following code at the end of the program. ret = fflush(stdout); if (ret < 0) { /* error handling */ } However, it is tedious to check the return code in all the call sites of printf(), fflush(), fclose(), and whatever can cause actual writes to the end device. Doing that lets the program bail out at the first failure but is usually not worth the effort. Instead, let's check the error status from ferror(). This is 'sticky', so you need to check it just once. You still need to call fflush(). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: David Laight <david.laight@aculab.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-03-06 16:25:35 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: use existing helper to check modular CONFIG options str_ends_with() tests if the given token ends with a particular string. Currently, it is used to check file paths without $(srctree). Actually, we have one more place where this helper is useful. Use it to check if CONFIG option ends with _MODULE. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:46 +09:00
fixdep: faster CONFIG_ search Do you think kernel build is 100% dominated by gcc? You are wrong! One small utility called "fixdep" consistently manages to sneak into profile's first page (unless you have small monitor of course). The choke point is this clever code: for (; m < end; m++) { if (*m == INT_CONF) { p = (char *) m ; goto conf; } if (*m == INT_ONFI) { p = (char *) m-1; goto conf; } if (*m == INT_NFIG) { p = (char *) m-2; goto conf; } if (*m == INT_FIG_) { p = (char *) m-3; goto conf; } 4 branches per 4 characters is not fast. Use strstr(3), so that SSE2 etc can be used. With this patch, fixdep is so deep at the bottom, it is hard to find it. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-08-24 21:03:05 +03:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: faster CONFIG_ search Do you think kernel build is 100% dominated by gcc? You are wrong! One small utility called "fixdep" consistently manages to sneak into profile's first page (unless you have small monitor of course). The choke point is this clever code: for (; m < end; m++) { if (*m == INT_CONF) { p = (char *) m ; goto conf; } if (*m == INT_ONFI) { p = (char *) m-1; goto conf; } if (*m == INT_NFIG) { p = (char *) m-2; goto conf; } if (*m == INT_FIG_) { p = (char *) m-3; goto conf; } 4 branches per 4 characters is not fast. Use strstr(3), so that SSE2 etc can be used. With this patch, fixdep is so deep at the bottom, it is hard to find it. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-08-24 21:03:05 +03:00
fixdep: remove some false CONFIG_ matches The string CONFIG_ quite often appears after other alphanumerics, meaning that that instance cannot be referencing a Kconfig symbol. Omitting these means make has fewer files to stat() when deciding what needs to be rebuilt - for a defconfig build, this seems to remove about 2% of the (wildcard ...) lines from the .o.cmd files. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-02-28 20:17:36 +01:00
fixdep: faster CONFIG_ search Do you think kernel build is 100% dominated by gcc? You are wrong! One small utility called "fixdep" consistently manages to sneak into profile's first page (unless you have small monitor of course). The choke point is this clever code: for (; m < end; m++) { if (*m == INT_CONF) { p = (char *) m ; goto conf; } if (*m == INT_ONFI) { p = (char *) m-1; goto conf; } if (*m == INT_NFIG) { p = (char *) m-2; goto conf; } if (*m == INT_FIG_) { p = (char *) m-3; goto conf; } 4 branches per 4 characters is not fast. Use strstr(3), so that SSE2 etc can be used. With this patch, fixdep is so deep at the bottom, it is hard to find it. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-08-24 21:03:05 +03:00
fixdep: remove some false CONFIG_ matches The string CONFIG_ quite often appears after other alphanumerics, meaning that that instance cannot be referencing a Kconfig symbol. Omitting these means make has fewer files to stat() when deciding what needs to be rebuilt - for a defconfig build, this seems to remove about 2% of the (wildcard ...) lines from the .o.cmd files. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-02-28 20:17:36 +01:00
kbuild: fixdep: optimize code slightly If the target string matches "CONFIG_", move the pointer p forward. This saves several 7-chars adjustments. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Michal Marek <mmarek@suse.com>
2015-07-24 14:18:45 +09:00
fixdep: faster CONFIG_ search Do you think kernel build is 100% dominated by gcc? You are wrong! One small utility called "fixdep" consistently manages to sneak into profile's first page (unless you have small monitor of course). The choke point is this clever code: for (; m < end; m++) { if (*m == INT_CONF) { p = (char *) m ; goto conf; } if (*m == INT_ONFI) { p = (char *) m-1; goto conf; } if (*m == INT_NFIG) { p = (char *) m-2; goto conf; } if (*m == INT_FIG_) { p = (char *) m-3; goto conf; } 4 branches per 4 characters is not fast. Use strstr(3), so that SSE2 etc can be used. With this patch, fixdep is so deep at the bottom, it is hard to find it. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-08-24 21:03:05 +03:00
fixdep: remove redundant null character check If *q is '\0', the condition (isalnum(*q) || *q == '_') is false anyway. It is redundant to ensure non-zero *q. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-02-18 19:00:31 +09:00
fixdep: faster CONFIG_ search Do you think kernel build is 100% dominated by gcc? You are wrong! One small utility called "fixdep" consistently manages to sneak into profile's first page (unless you have small monitor of course). The choke point is this clever code: for (; m < end; m++) { if (*m == INT_CONF) { p = (char *) m ; goto conf; } if (*m == INT_ONFI) { p = (char *) m-1; goto conf; } if (*m == INT_NFIG) { p = (char *) m-2; goto conf; } if (*m == INT_FIG_) { p = (char *) m-3; goto conf; } 4 branches per 4 characters is not fast. Use strstr(3), so that SSE2 etc can be used. With this patch, fixdep is so deep at the bottom, it is hard to find it. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-08-24 21:03:05 +03:00
fixdep: use existing helper to check modular CONFIG options str_ends_with() tests if the given token ends with a particular string. Currently, it is used to check file paths without $(srctree). Actually, we have one more place where this helper is useful. Use it to check if CONFIG option ends with _MODULE. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:46 +09:00
fixdep: faster CONFIG_ search Do you think kernel build is 100% dominated by gcc? You are wrong! One small utility called "fixdep" consistently manages to sneak into profile's first page (unless you have small monitor of course). The choke point is this clever code: for (; m < end; m++) { if (*m == INT_CONF) { p = (char *) m ; goto conf; } if (*m == INT_ONFI) { p = (char *) m-1; goto conf; } if (*m == INT_NFIG) { p = (char *) m-2; goto conf; } if (*m == INT_FIG_) { p = (char *) m-3; goto conf; } 4 branches per 4 characters is not fast. Use strstr(3), so that SSE2 etc can be used. With this patch, fixdep is so deep at the bottom, it is hard to find it. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-08-24 21:03:05 +03:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: factor out common code for reading files Now, do_config_files() and print_deps() are almost the same. Only the difference is the parser function called (parse_config_file vs parse_dep_file). We can reduce the code duplication by factoring out the common code into read_file() - this function allocates a buffer and loads a file to it. It returns the pointer to the allocated buffer. (As before, it bails out by exit(2) for any error.) The caller must free the buffer when done. Having empty source files is possible; fixdep should simply skip them. I deleted the "st.st_size == 0" check, so read_file() allocates 1-byte buffer for an empty file. strstr() will immediately return NULL, and this is what we expect. On the other hand, an empty dep_file should be treated as an error. In this case, parse_dep_file() will error out with "no targets found" and it is a correct error message. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:42 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: factor out common code for reading files Now, do_config_files() and print_deps() are almost the same. Only the difference is the parser function called (parse_config_file vs parse_dep_file). We can reduce the code duplication by factoring out the common code into read_file() - this function allocates a buffer and loads a file to it. It returns the pointer to the allocated buffer. (As before, it bails out by exit(2) for any error.) The caller must free the buffer when done. Having empty source files is possible; fixdep should simply skip them. I deleted the "st.st_size == 0" check, so read_file() allocates 1-byte buffer for an empty file. strstr() will immediately return NULL, and this is what we expect. On the other hand, an empty dep_file should be treated as an error. In this case, parse_dep_file() will error out with "no targets found" and it is a correct error message. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:42 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: factor out common code for reading files Now, do_config_files() and print_deps() are almost the same. Only the difference is the parser function called (parse_config_file vs parse_dep_file). We can reduce the code duplication by factoring out the common code into read_file() - this function allocates a buffer and loads a file to it. It returns the pointer to the allocated buffer. (As before, it bails out by exit(2) for any error.) The caller must free the buffer when done. Having empty source files is possible; fixdep should simply skip them. I deleted the "st.st_size == 0" check, so read_file() allocates 1-byte buffer for an empty file. strstr() will immediately return NULL, and this is what we expect. On the other hand, an empty dep_file should be treated as an error. In this case, parse_dep_file() will error out with "no targets found" and it is a correct error message. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:42 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kbuild: fixdep: Check fstat(2) return value Coverity has recently added a check that will find when we don't check the return code from fstat(2). Copy/paste the checking logic that print_deps() has with an appropriate re-wording of the perror() message. Signed-off-by: Tom Rini <trini@konsulko.com> Signed-off-by: Michal Marek <mmarek@suse.com>
2015-12-07 16:26:08 -05:00
fixdep: factor out common code for reading files Now, do_config_files() and print_deps() are almost the same. Only the difference is the parser function called (parse_config_file vs parse_dep_file). We can reduce the code duplication by factoring out the common code into read_file() - this function allocates a buffer and loads a file to it. It returns the pointer to the allocated buffer. (As before, it bails out by exit(2) for any error.) The caller must free the buffer when done. Having empty source files is possible; fixdep should simply skip them. I deleted the "st.st_size == 0" check, so read_file() allocates 1-byte buffer for an empty file. strstr() will immediately return NULL, and this is what we expect. On the other hand, an empty dep_file should be treated as an error. In this case, parse_dep_file() will error out with "no targets found" and it is a correct error message. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:42 +09:00
kbuild: fixdep: Check fstat(2) return value Coverity has recently added a check that will find when we don't check the return code from fstat(2). Copy/paste the checking logic that print_deps() has with an appropriate re-wording of the perror() message. Signed-off-by: Tom Rini <trini@konsulko.com> Signed-off-by: Michal Marek <mmarek@suse.com>
2015-12-07 16:26:08 -05:00
fixdep: factor out common code for reading files Now, do_config_files() and print_deps() are almost the same. Only the difference is the parser function called (parse_config_file vs parse_dep_file). We can reduce the code duplication by factoring out the common code into read_file() - this function allocates a buffer and loads a file to it. It returns the pointer to the allocated buffer. (As before, it bails out by exit(2) for any error.) The caller must free the buffer when done. Having empty source files is possible; fixdep should simply skip them. I deleted the "st.st_size == 0" check, so read_file() allocates 1-byte buffer for an empty file. strstr() will immediately return NULL, and this is what we expect. On the other hand, an empty dep_file should be treated as an error. In this case, parse_dep_file() will error out with "no targets found" and it is a correct error message. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:42 +09:00
fixdep: faster CONFIG_ search Do you think kernel build is 100% dominated by gcc? You are wrong! One small utility called "fixdep" consistently manages to sneak into profile's first page (unless you have small monitor of course). The choke point is this clever code: for (; m < end; m++) { if (*m == INT_CONF) { p = (char *) m ; goto conf; } if (*m == INT_ONFI) { p = (char *) m-1; goto conf; } if (*m == INT_NFIG) { p = (char *) m-2; goto conf; } if (*m == INT_FIG_) { p = (char *) m-3; goto conf; } 4 branches per 4 characters is not fast. Use strstr(3), so that SSE2 etc can be used. With this patch, fixdep is so deep at the bottom, it is hard to find it. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-08-24 21:03:05 +03:00
fixdep: exit with error code in error branches of do_config_file() do_config_file() should exit with an error code on internal run-time errors, and not return if it fails as then the error in do_config_file() would go unnoticed in the current code and allow the build to continue. The exit with error code will make the build fail in those very exceptional cases. If this occurs, this actually indicates a deeper problem in the execution of the kernel build process. Now, in these error cases, we do not explicitly free memory and close the file handlers in do_config_file(), as this is covered by exit(). This issue in the fixdep script was introduced with its initial implementation back in 2002 by the original author Kai Germaschewski with this commit 04bd72170653 ("kbuild: Make dependencies at compile time") in the linux history git tree, i.e., git://git.kernel.org/pub/scm/linux/kernel/git/history/history.git. This issue was identified during the review of a previous patch that intended to address a memory leak detected by a static analysis tool. Link: https://lkml.org/lkml/2017/12/14/736 Suggested-by: Nicholas Mc Guire <der.herr@hofr.at> Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-08 11:04:01 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: factor out common code for reading files Now, do_config_files() and print_deps() are almost the same. Only the difference is the parser function called (parse_config_file vs parse_dep_file). We can reduce the code duplication by factoring out the common code into read_file() - this function allocates a buffer and loads a file to it. It returns the pointer to the allocated buffer. (As before, it bails out by exit(2) for any error.) The caller must free the buffer when done. Having empty source files is possible; fixdep should simply skip them. I deleted the "st.st_size == 0" check, so read_file() allocates 1-byte buffer for an empty file. strstr() will immediately return NULL, and this is what we expect. On the other hand, an empty dep_file should be treated as an error. In this case, parse_dep_file() will error out with "no targets found" and it is a correct error message. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:42 +09:00
fixdep: faster CONFIG_ search Do you think kernel build is 100% dominated by gcc? You are wrong! One small utility called "fixdep" consistently manages to sneak into profile's first page (unless you have small monitor of course). The choke point is this clever code: for (; m < end; m++) { if (*m == INT_CONF) { p = (char *) m ; goto conf; } if (*m == INT_ONFI) { p = (char *) m-1; goto conf; } if (*m == INT_NFIG) { p = (char *) m-2; goto conf; } if (*m == INT_FIG_) { p = (char *) m-3; goto conf; } 4 branches per 4 characters is not fast. Use strstr(3), so that SSE2 etc can be used. With this patch, fixdep is so deep at the bottom, it is hard to find it. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-08-24 21:03:05 +03:00
fixdep: exit with error code in error branches of do_config_file() do_config_file() should exit with an error code on internal run-time errors, and not return if it fails as then the error in do_config_file() would go unnoticed in the current code and allow the build to continue. The exit with error code will make the build fail in those very exceptional cases. If this occurs, this actually indicates a deeper problem in the execution of the kernel build process. Now, in these error cases, we do not explicitly free memory and close the file handlers in do_config_file(), as this is covered by exit(). This issue in the fixdep script was introduced with its initial implementation back in 2002 by the original author Kai Germaschewski with this commit 04bd72170653 ("kbuild: Make dependencies at compile time") in the linux history git tree, i.e., git://git.kernel.org/pub/scm/linux/kernel/git/history/history.git. This issue was identified during the review of a previous patch that intended to address a memory leak detected by a static analysis tool. Link: https://lkml.org/lkml/2017/12/14/736 Suggested-by: Nicholas Mc Guire <der.herr@hofr.at> Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-08 11:04:01 +01:00
fixdep: faster CONFIG_ search Do you think kernel build is 100% dominated by gcc? You are wrong! One small utility called "fixdep" consistently manages to sneak into profile's first page (unless you have small monitor of course). The choke point is this clever code: for (; m < end; m++) { if (*m == INT_CONF) { p = (char *) m ; goto conf; } if (*m == INT_ONFI) { p = (char *) m-1; goto conf; } if (*m == INT_NFIG) { p = (char *) m-2; goto conf; } if (*m == INT_FIG_) { p = (char *) m-3; goto conf; } 4 branches per 4 characters is not fast. Use strstr(3), so that SSE2 etc can be used. With this patch, fixdep is so deep at the bottom, it is hard to find it. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-08-24 21:03:05 +03:00
fixdep: factor out common code for reading files Now, do_config_files() and print_deps() are almost the same. Only the difference is the parser function called (parse_config_file vs parse_dep_file). We can reduce the code duplication by factoring out the common code into read_file() - this function allocates a buffer and loads a file to it. It returns the pointer to the allocated buffer. (As before, it bails out by exit(2) for any error.) The caller must free the buffer when done. Having empty source files is possible; fixdep should simply skip them. I deleted the "st.st_size == 0" check, so read_file() allocates 1-byte buffer for an empty file. strstr() will immediately return NULL, and this is what we expect. On the other hand, an empty dep_file should be treated as an error. In this case, parse_dep_file() will error out with "no targets found" and it is a correct error message. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:42 +09:00
fixdep: faster CONFIG_ search Do you think kernel build is 100% dominated by gcc? You are wrong! One small utility called "fixdep" consistently manages to sneak into profile's first page (unless you have small monitor of course). The choke point is this clever code: for (; m < end; m++) { if (*m == INT_CONF) { p = (char *) m ; goto conf; } if (*m == INT_ONFI) { p = (char *) m-1; goto conf; } if (*m == INT_NFIG) { p = (char *) m-2; goto conf; } if (*m == INT_FIG_) { p = (char *) m-3; goto conf; } 4 branches per 4 characters is not fast. Use strstr(3), so that SSE2 etc can be used. With this patch, fixdep is so deep at the bottom, it is hard to find it. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.com>
2016-08-24 21:03:05 +03:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: factor out common code for reading files Now, do_config_files() and print_deps() are almost the same. Only the difference is the parser function called (parse_config_file vs parse_dep_file). We can reduce the code duplication by factoring out the common code into read_file() - this function allocates a buffer and loads a file to it. It returns the pointer to the allocated buffer. (As before, it bails out by exit(2) for any error.) The caller must free the buffer when done. Having empty source files is possible; fixdep should simply skip them. I deleted the "st.st_size == 0" check, so read_file() allocates 1-byte buffer for an empty file. strstr() will immediately return NULL, and this is what we expect. On the other hand, an empty dep_file should be treated as an error. In this case, parse_dep_file() will error out with "no targets found" and it is a correct error message. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:42 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: refactor parse_dep_file() parse_dep_file() has too much indentation, and puts the code far to the right. This commit refactors the code and reduces the one level of indentation. strrcmp() computes 'slen' by itself, but the caller already knows the length of the token, so 'slen' can be passed via function argument. With this, we can swap the order of strrcmp() and "*p = \0;" Also, strrcmp() is an ambiguous function name. Flip the logic and rename it to str_ends_with(). I added a new helper is_ignored_file() - this returns 1 if the token represents a file that should be ignored. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:45 +09:00
fixdep: remove unneeded code and comments about *.ver files This is probably stale code. In old days (~ Linux 2.5.59), Kbuild made genksyms generate include/linux/modules/*.ver files. The currenct Kbuild does not generate *.ver files at all. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-02-18 18:58:59 +09:00
fixdep: refactor parse_dep_file() parse_dep_file() has too much indentation, and puts the code far to the right. This commit refactors the code and reduces the one level of indentation. strrcmp() computes 'slen' by itself, but the caller already knows the length of the token, so 'slen' can be passed via function argument. With this, we can swap the order of strrcmp() and "*p = \0;" Also, strrcmp() is an ambiguous function name. Flip the logic and rename it to str_ends_with(). I added a new helper is_ignored_file() - this returns 1 if the token represents a file that should be ignored. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:45 +09:00
kbuild: Fix computing srcversion for modules Recent change to fixdep: commit b7bd182176960fdd139486cadb9962b39f8a2b50 Author: Michal Marek <mmarek@suse.cz> Date: Thu Feb 17 15:13:54 2011 +0100 fixdep: Do not record dependency on the source file itself changed the format of the *.cmd files without realizing that it is also used by modpost. Put the path to the source file to the file back, in a special variable, so that modpost sees all source files when calculating srcversion for modules. Reported-and-tested-by: Henrik Rydberg <rydberg@euromail.se> Signed-off-by: Michal Marek <mmarek@suse.cz> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-03-11 22:34:47 +01:00
kbuild: simplify dependency generation for CONFIG_TRIM_UNUSED_KSYMS My main motivation of this commit is to clean up scripts/Kbuild.include and scripts/Makefile.build. Currently, CONFIG_TRIM_UNUSED_KSYMS works with a tricky gimmick; possibly exported symbols are detected by letting $(CPP) replace EXPORT_SYMBOL* with a special string '=== __KSYM_*===', which is post-processed by sed, and passed to fixdep. The extra preprocessing is costly, and hacking cmd_and_fixdep is ugly. I came up with a new way to find exported symbols; insert a dummy symbol __ksym_marker_* to each potentially exported symbol. Those dummy symbols are picked up by $(NM), post-processed by sed, then appended to .*.cmd files. I collected the post-process part to a new shell script scripts/gen_ksymdeps.sh for readability. The dummy symbols are put into the .discard.* section so that the linker script rips them off the final vmlinux or modules. A nice side-effect is building with CONFIG_TRIM_UNUSED_KSYMS will be much faster. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Nicolas Pitre <nico@linaro.org>
2018-11-30 10:05:26 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] Kill signed chars scripts/ is full of mismatches between char* params an signed char* arguments, and viceversa. gcc4 now complaints loud about this. Patch below deletes all those 'signed'. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25 14:59:22 -07:00
fixdep: use malloc() and read() to load dep_file to buffer Commit dee81e988674 ("fixdep: faster CONFIG_ search") changed how to read files in which CONFIG options are searched. It used malloc() and read() instead of mmap() because it needed to zero-terminate the buffer in order to use strstr(). print_deps() was left untouched since there was no reason to change it. Now, I have two motivations to change it in the same way. - do_config_file() and print_deps() do quite similar things; they open a file, load it onto memory, and pass it to a parser function. If we use malloc() and read() for print_deps() too, we can factor out the common code. (I will do this in the next commit.) - parse_dep_file() copies each token to a temporary buffer because it needs to zero-terminate it to be passed to printf(). It is not possible to modify the buffer directly because it is mmap'ed with O_RDONLY. If we load the file content into a malloc'ed buffer, we can insert '\0' after each token, and save memcpy(). (I will do this in the commit after next.) Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:41 +09:00
kbuild: fixdep: support concatenated dep files The current use-case for fixdep is: a source file is run through a single processing step, which creates a single dependency file as a side-effect, which fixdep transforms into the file used by the kernel build process. In order to transparently run the C pre-processor on device-tree files, we wish to run both gcc -E and dtc on a source file in a single rule. This generates two dependency files, which must be transformed together into the file used by the kernel build process. This change modifies fixdep so it can process the concatenation of multiple separate input dependency files, and produce a correct unified output. The code changes have the slight benefit of transforming the loop in parse_dep_file() into more of a lexer/tokenizer, with the loop body being more of a parser. Previously, some of this logic was mixed together before the loop. I also added some comments, which I hope are useful. Benchmarking shows that on a cross-compiled ARM tegra_defconfig build, there is less than 0.5 seconds speed decrease with this change, on top of a build time of ~2m24s. This is probably within the noise. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Rob Herring <rob.herring@calxeda.com>
2013-03-06 10:27:45 -07:00
fixdep: factor out common code for reading files Now, do_config_files() and print_deps() are almost the same. Only the difference is the parser function called (parse_config_file vs parse_dep_file). We can reduce the code duplication by factoring out the common code into read_file() - this function allocates a buffer and loads a file to it. It returns the pointer to the allocated buffer. (As before, it bails out by exit(2) for any error.) The caller must free the buffer when done. Having empty source files is possible; fixdep should simply skip them. I deleted the "st.st_size == 0" check, so read_file() allocates 1-byte buffer for an empty file. strstr() will immediately return NULL, and this is what we expect. On the other hand, an empty dep_file should be treated as an error. In this case, parse_dep_file() will error out with "no targets found" and it is a correct error message. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:42 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: use malloc() and read() to load dep_file to buffer Commit dee81e988674 ("fixdep: faster CONFIG_ search") changed how to read files in which CONFIG options are searched. It used malloc() and read() instead of mmap() because it needed to zero-terminate the buffer in order to use strstr(). print_deps() was left untouched since there was no reason to change it. Now, I have two motivations to change it in the same way. - do_config_file() and print_deps() do quite similar things; they open a file, load it onto memory, and pass it to a parser function. If we use malloc() and read() for print_deps() too, we can factor out the common code. (I will do this in the next commit.) - parse_dep_file() copies each token to a temporary buffer because it needs to zero-terminate it to be passed to printf(). It is not possible to modify the buffer directly because it is mmap'ed with O_RDONLY. If we load the file content into a malloc'ed buffer, we can insert '\0' after each token, and save memcpy(). (I will do this in the commit after next.) Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:41 +09:00
kbuild: fixdep: support concatenated dep files The current use-case for fixdep is: a source file is run through a single processing step, which creates a single dependency file as a side-effect, which fixdep transforms into the file used by the kernel build process. In order to transparently run the C pre-processor on device-tree files, we wish to run both gcc -E and dtc on a source file in a single rule. This generates two dependency files, which must be transformed together into the file used by the kernel build process. This change modifies fixdep so it can process the concatenation of multiple separate input dependency files, and produce a correct unified output. The code changes have the slight benefit of transforming the loop in parse_dep_file() into more of a lexer/tokenizer, with the loop body being more of a parser. Previously, some of this logic was mixed together before the loop. I also added some comments, which I hope are useful. Benchmarking shows that on a cross-compiled ARM tegra_defconfig build, there is less than 0.5 seconds speed decrease with this change, on top of a build time of ~2m24s. This is probably within the noise. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Rob Herring <rob.herring@calxeda.com>
2013-03-06 10:27:45 -07:00
fixdep: use malloc() and read() to load dep_file to buffer Commit dee81e988674 ("fixdep: faster CONFIG_ search") changed how to read files in which CONFIG options are searched. It used malloc() and read() instead of mmap() because it needed to zero-terminate the buffer in order to use strstr(). print_deps() was left untouched since there was no reason to change it. Now, I have two motivations to change it in the same way. - do_config_file() and print_deps() do quite similar things; they open a file, load it onto memory, and pass it to a parser function. If we use malloc() and read() for print_deps() too, we can factor out the common code. (I will do this in the next commit.) - parse_dep_file() copies each token to a temporary buffer because it needs to zero-terminate it to be passed to printf(). It is not possible to modify the buffer directly because it is mmap'ed with O_RDONLY. If we load the file content into a malloc'ed buffer, we can insert '\0' after each token, and save memcpy(). (I will do this in the commit after next.) Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:41 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: use malloc() and read() to load dep_file to buffer Commit dee81e988674 ("fixdep: faster CONFIG_ search") changed how to read files in which CONFIG options are searched. It used malloc() and read() instead of mmap() because it needed to zero-terminate the buffer in order to use strstr(). print_deps() was left untouched since there was no reason to change it. Now, I have two motivations to change it in the same way. - do_config_file() and print_deps() do quite similar things; they open a file, load it onto memory, and pass it to a parser function. If we use malloc() and read() for print_deps() too, we can factor out the common code. (I will do this in the next commit.) - parse_dep_file() copies each token to a temporary buffer because it needs to zero-terminate it to be passed to printf(). It is not possible to modify the buffer directly because it is mmap'ed with O_RDONLY. If we load the file content into a malloc'ed buffer, we can insert '\0' after each token, and save memcpy(). (I will do this in the commit after next.) Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:41 +09:00
kbuild: fixdep: support concatenated dep files The current use-case for fixdep is: a source file is run through a single processing step, which creates a single dependency file as a side-effect, which fixdep transforms into the file used by the kernel build process. In order to transparently run the C pre-processor on device-tree files, we wish to run both gcc -E and dtc on a source file in a single rule. This generates two dependency files, which must be transformed together into the file used by the kernel build process. This change modifies fixdep so it can process the concatenation of multiple separate input dependency files, and produce a correct unified output. The code changes have the slight benefit of transforming the loop in parse_dep_file() into more of a lexer/tokenizer, with the loop body being more of a parser. Previously, some of this logic was mixed together before the loop. I also added some comments, which I hope are useful. Benchmarking shows that on a cross-compiled ARM tegra_defconfig build, there is less than 0.5 seconds speed decrease with this change, on top of a build time of ~2m24s. This is probably within the noise. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Rob Herring <rob.herring@calxeda.com>
2013-03-06 10:27:45 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: use malloc() and read() to load dep_file to buffer Commit dee81e988674 ("fixdep: faster CONFIG_ search") changed how to read files in which CONFIG options are searched. It used malloc() and read() instead of mmap() because it needed to zero-terminate the buffer in order to use strstr(). print_deps() was left untouched since there was no reason to change it. Now, I have two motivations to change it in the same way. - do_config_file() and print_deps() do quite similar things; they open a file, load it onto memory, and pass it to a parser function. If we use malloc() and read() for print_deps() too, we can factor out the common code. (I will do this in the next commit.) - parse_dep_file() copies each token to a temporary buffer because it needs to zero-terminate it to be passed to printf(). It is not possible to modify the buffer directly because it is mmap'ed with O_RDONLY. If we load the file content into a malloc'ed buffer, we can insert '\0' after each token, and save memcpy(). (I will do this in the commit after next.) Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:41 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: use malloc() and read() to load dep_file to buffer Commit dee81e988674 ("fixdep: faster CONFIG_ search") changed how to read files in which CONFIG options are searched. It used malloc() and read() instead of mmap() because it needed to zero-terminate the buffer in order to use strstr(). print_deps() was left untouched since there was no reason to change it. Now, I have two motivations to change it in the same way. - do_config_file() and print_deps() do quite similar things; they open a file, load it onto memory, and pass it to a parser function. If we use malloc() and read() for print_deps() too, we can factor out the common code. (I will do this in the next commit.) - parse_dep_file() copies each token to a temporary buffer because it needs to zero-terminate it to be passed to printf(). It is not possible to modify the buffer directly because it is mmap'ed with O_RDONLY. If we load the file content into a malloc'ed buffer, we can insert '\0' after each token, and save memcpy(). (I will do this in the commit after next.) Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:41 +09:00
kbuild: fixdep: support concatenated dep files The current use-case for fixdep is: a source file is run through a single processing step, which creates a single dependency file as a side-effect, which fixdep transforms into the file used by the kernel build process. In order to transparently run the C pre-processor on device-tree files, we wish to run both gcc -E and dtc on a source file in a single rule. This generates two dependency files, which must be transformed together into the file used by the kernel build process. This change modifies fixdep so it can process the concatenation of multiple separate input dependency files, and produce a correct unified output. The code changes have the slight benefit of transforming the loop in parse_dep_file() into more of a lexer/tokenizer, with the loop body being more of a parser. Previously, some of this logic was mixed together before the loop. I also added some comments, which I hope are useful. Benchmarking shows that on a cross-compiled ARM tegra_defconfig build, there is less than 0.5 seconds speed decrease with this change, on top of a build time of ~2m24s. This is probably within the noise. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Rob Herring <rob.herring@calxeda.com>
2013-03-06 10:27:45 -07:00
fixdep: refactor parse_dep_file() parse_dep_file() has too much indentation, and puts the code far to the right. This commit refactors the code and reduces the one level of indentation. strrcmp() computes 'slen' by itself, but the caller already knows the length of the token, so 'slen' can be passed via function argument. With this, we can swap the order of strrcmp() and "*p = \0;" Also, strrcmp() is an ambiguous function name. Flip the logic and rename it to str_ends_with(). I added a new helper is_ignored_file() - this returns 1 if the token represents a file that should be ignored. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:45 +09:00
fixdep: remove unneeded memcpy() in parse_dep_file() Each token in the depfile is copied to the temporary buffer 's' to terminate the token with zero. We do not need to do this any more because the parsed buffer is now writable. Insert '\0' directly in the buffer without calling memcpy(). <limits.h> is no longer necessary. (It was needed for PATH_MAX). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:43 +09:00
kbuild: fixdep: support concatenated dep files The current use-case for fixdep is: a source file is run through a single processing step, which creates a single dependency file as a side-effect, which fixdep transforms into the file used by the kernel build process. In order to transparently run the C pre-processor on device-tree files, we wish to run both gcc -E and dtc on a source file in a single rule. This generates two dependency files, which must be transformed together into the file used by the kernel build process. This change modifies fixdep so it can process the concatenation of multiple separate input dependency files, and produce a correct unified output. The code changes have the slight benefit of transforming the loop in parse_dep_file() into more of a lexer/tokenizer, with the loop body being more of a parser. Previously, some of this logic was mixed together before the loop. I also added some comments, which I hope are useful. Benchmarking shows that on a cross-compiled ARM tegra_defconfig build, there is less than 0.5 seconds speed decrease with this change, on top of a build time of ~2m24s. This is probably within the noise. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Rob Herring <rob.herring@calxeda.com>
2013-03-06 10:27:45 -07:00
fixdep: refactor parse_dep_file() parse_dep_file() has too much indentation, and puts the code far to the right. This commit refactors the code and reduces the one level of indentation. strrcmp() computes 'slen' by itself, but the caller already knows the length of the token, so 'slen' can be passed via function argument. With this, we can swap the order of strrcmp() and "*p = \0;" Also, strrcmp() is an ambiguous function name. Flip the logic and rename it to str_ends_with(). I added a new helper is_ignored_file() - this returns 1 if the token represents a file that should be ignored. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:45 +09:00
kbuild: fixdep: support concatenated dep files The current use-case for fixdep is: a source file is run through a single processing step, which creates a single dependency file as a side-effect, which fixdep transforms into the file used by the kernel build process. In order to transparently run the C pre-processor on device-tree files, we wish to run both gcc -E and dtc on a source file in a single rule. This generates two dependency files, which must be transformed together into the file used by the kernel build process. This change modifies fixdep so it can process the concatenation of multiple separate input dependency files, and produce a correct unified output. The code changes have the slight benefit of transforming the loop in parse_dep_file() into more of a lexer/tokenizer, with the loop body being more of a parser. Previously, some of this logic was mixed together before the loop. I also added some comments, which I hope are useful. Benchmarking shows that on a cross-compiled ARM tegra_defconfig build, there is less than 0.5 seconds speed decrease with this change, on top of a build time of ~2m24s. This is probably within the noise. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Rob Herring <rob.herring@calxeda.com>
2013-03-06 10:27:45 -07:00
fixdep: refactor parse_dep_file() parse_dep_file() has too much indentation, and puts the code far to the right. This commit refactors the code and reduces the one level of indentation. strrcmp() computes 'slen' by itself, but the caller already knows the length of the token, so 'slen' can be passed via function argument. With this, we can swap the order of strrcmp() and "*p = \0;" Also, strrcmp() is an ambiguous function name. Flip the logic and rename it to str_ends_with(). I added a new helper is_ignored_file() - this returns 1 if the token represents a file that should be ignored. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:45 +09:00
kbuild: fixdep: support concatenated dep files The current use-case for fixdep is: a source file is run through a single processing step, which creates a single dependency file as a side-effect, which fixdep transforms into the file used by the kernel build process. In order to transparently run the C pre-processor on device-tree files, we wish to run both gcc -E and dtc on a source file in a single rule. This generates two dependency files, which must be transformed together into the file used by the kernel build process. This change modifies fixdep so it can process the concatenation of multiple separate input dependency files, and produce a correct unified output. The code changes have the slight benefit of transforming the loop in parse_dep_file() into more of a lexer/tokenizer, with the loop body being more of a parser. Previously, some of this logic was mixed together before the loop. I also added some comments, which I hope are useful. Benchmarking shows that on a cross-compiled ARM tegra_defconfig build, there is less than 0.5 seconds speed decrease with this change, on top of a build time of ~2m24s. This is probably within the noise. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Rob Herring <rob.herring@calxeda.com>
2013-03-06 10:27:45 -07:00
fixdep: refactor parse_dep_file() parse_dep_file() has too much indentation, and puts the code far to the right. This commit refactors the code and reduces the one level of indentation. strrcmp() computes 'slen' by itself, but the caller already knows the length of the token, so 'slen' can be passed via function argument. With this, we can swap the order of strrcmp() and "*p = \0;" Also, strrcmp() is an ambiguous function name. Flip the logic and rename it to str_ends_with(). I added a new helper is_ignored_file() - this returns 1 if the token represents a file that should be ignored. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:45 +09:00
fixdep: use fflush() and ferror() to ensure successful write to files Currently, fixdep checks the return value from (v)printf(), but it does not ensure the complete write to the .cmd file. printf() just writes data to the internal buffer, which usually succeeds. (Of course, it may fail for another reason, for example when the file descriptor is closed, but that is another story.) When the buffer (4k?) is full, an actual write occurs, and printf() may really fail. One of typical cases is "No space left on device" when the disk is full. The data remaining in the buffer will be pushed out to the file when the program exits, but we never know if it is successful. One straight-forward fix would be to add the following code at the end of the program. ret = fflush(stdout); if (ret < 0) { /* error handling */ } However, it is tedious to check the return code in all the call sites of printf(), fflush(), fclose(), and whatever can cause actual writes to the end device. Doing that lets the program bail out at the first failure but is usually not worth the effort. Instead, let's check the error status from ferror(). This is 'sticky', so you need to check it just once. You still need to call fflush(). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: David Laight <david.laight@aculab.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-03-06 16:25:35 +09:00
fixdep: refactor parse_dep_file() parse_dep_file() has too much indentation, and puts the code far to the right. This commit refactors the code and reduces the one level of indentation. strrcmp() computes 'slen' by itself, but the caller already knows the length of the token, so 'slen' can be passed via function argument. With this, we can swap the order of strrcmp() and "*p = \0;" Also, strrcmp() is an ambiguous function name. Flip the logic and rename it to str_ends_with(). I added a new helper is_ignored_file() - this returns 1 if the token represents a file that should be ignored. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:45 +09:00
fixdep: use fflush() and ferror() to ensure successful write to files Currently, fixdep checks the return value from (v)printf(), but it does not ensure the complete write to the .cmd file. printf() just writes data to the internal buffer, which usually succeeds. (Of course, it may fail for another reason, for example when the file descriptor is closed, but that is another story.) When the buffer (4k?) is full, an actual write occurs, and printf() may really fail. One of typical cases is "No space left on device" when the disk is full. The data remaining in the buffer will be pushed out to the file when the program exits, but we never know if it is successful. One straight-forward fix would be to add the following code at the end of the program. ret = fflush(stdout); if (ret < 0) { /* error handling */ } However, it is tedious to check the return code in all the call sites of printf(), fflush(), fclose(), and whatever can cause actual writes to the end device. Doing that lets the program bail out at the first failure but is usually not worth the effort. Instead, let's check the error status from ferror(). This is 'sticky', so you need to check it just once. You still need to call fflush(). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: David Laight <david.laight@aculab.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-03-06 16:25:35 +09:00
kbuild: fixdep: support concatenated dep files The current use-case for fixdep is: a source file is run through a single processing step, which creates a single dependency file as a side-effect, which fixdep transforms into the file used by the kernel build process. In order to transparently run the C pre-processor on device-tree files, we wish to run both gcc -E and dtc on a source file in a single rule. This generates two dependency files, which must be transformed together into the file used by the kernel build process. This change modifies fixdep so it can process the concatenation of multiple separate input dependency files, and produce a correct unified output. The code changes have the slight benefit of transforming the loop in parse_dep_file() into more of a lexer/tokenizer, with the loop body being more of a parser. Previously, some of this logic was mixed together before the loop. I also added some comments, which I hope are useful. Benchmarking shows that on a cross-compiled ARM tegra_defconfig build, there is less than 0.5 seconds speed decrease with this change, on top of a build time of ~2m24s. This is probably within the noise. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Rob Herring <rob.herring@calxeda.com>
2013-03-06 10:27:45 -07:00
fixdep: refactor parse_dep_file() parse_dep_file() has too much indentation, and puts the code far to the right. This commit refactors the code and reduces the one level of indentation. strrcmp() computes 'slen' by itself, but the caller already knows the length of the token, so 'slen' can be passed via function argument. With this, we can swap the order of strrcmp() and "*p = \0;" Also, strrcmp() is an ambiguous function name. Flip the logic and rename it to str_ends_with(). I added a new helper is_ignored_file() - this returns 1 if the token represents a file that should be ignored. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:45 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: use malloc() and read() to load dep_file to buffer Commit dee81e988674 ("fixdep: faster CONFIG_ search") changed how to read files in which CONFIG options are searched. It used malloc() and read() instead of mmap() because it needed to zero-terminate the buffer in order to use strstr(). print_deps() was left untouched since there was no reason to change it. Now, I have two motivations to change it in the same way. - do_config_file() and print_deps() do quite similar things; they open a file, load it onto memory, and pass it to a parser function. If we use malloc() and read() for print_deps() too, we can factor out the common code. (I will do this in the next commit.) - parse_dep_file() copies each token to a temporary buffer because it needs to zero-terminate it to be passed to printf(). It is not possible to modify the buffer directly because it is mmap'ed with O_RDONLY. If we load the file content into a malloc'ed buffer, we can insert '\0' after each token, and save memcpy(). (I will do this in the commit after next.) Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:41 +09:00
kbuild: fixdep: support concatenated dep files The current use-case for fixdep is: a source file is run through a single processing step, which creates a single dependency file as a side-effect, which fixdep transforms into the file used by the kernel build process. In order to transparently run the C pre-processor on device-tree files, we wish to run both gcc -E and dtc on a source file in a single rule. This generates two dependency files, which must be transformed together into the file used by the kernel build process. This change modifies fixdep so it can process the concatenation of multiple separate input dependency files, and produce a correct unified output. The code changes have the slight benefit of transforming the loop in parse_dep_file() into more of a lexer/tokenizer, with the loop body being more of a parser. Previously, some of this logic was mixed together before the loop. I also added some comments, which I hope are useful. Benchmarking shows that on a cross-compiled ARM tegra_defconfig build, there is less than 0.5 seconds speed decrease with this change, on top of a build time of ~2m24s. This is probably within the noise. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Rob Herring <rob.herring@calxeda.com>
2013-03-06 10:27:45 -07:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
kbuild: fixdep: support concatenated dep files The current use-case for fixdep is: a source file is run through a single processing step, which creates a single dependency file as a side-effect, which fixdep transforms into the file used by the kernel build process. In order to transparently run the C pre-processor on device-tree files, we wish to run both gcc -E and dtc on a source file in a single rule. This generates two dependency files, which must be transformed together into the file used by the kernel build process. This change modifies fixdep so it can process the concatenation of multiple separate input dependency files, and produce a correct unified output. The code changes have the slight benefit of transforming the loop in parse_dep_file() into more of a lexer/tokenizer, with the loop body being more of a parser. Previously, some of this logic was mixed together before the loop. I also added some comments, which I hope are useful. Benchmarking shows that on a cross-compiled ARM tegra_defconfig build, there is less than 0.5 seconds speed decrease with this change, on top of a build time of ~2m24s. This is probably within the noise. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Rob Herring <rob.herring@calxeda.com>
2013-03-06 10:27:45 -07:00
fixdep: use fflush() and ferror() to ensure successful write to files Currently, fixdep checks the return value from (v)printf(), but it does not ensure the complete write to the .cmd file. printf() just writes data to the internal buffer, which usually succeeds. (Of course, it may fail for another reason, for example when the file descriptor is closed, but that is another story.) When the buffer (4k?) is full, an actual write occurs, and printf() may really fail. One of typical cases is "No space left on device" when the disk is full. The data remaining in the buffer will be pushed out to the file when the program exits, but we never know if it is successful. One straight-forward fix would be to add the following code at the end of the program. ret = fflush(stdout); if (ret < 0) { /* error handling */ } However, it is tedious to check the return code in all the call sites of printf(), fflush(), fclose(), and whatever can cause actual writes to the end device. Doing that lets the program bail out at the first failure but is usually not worth the effort. Instead, let's check the error status from ferror(). This is 'sticky', so you need to check it just once. You still need to call fflush(). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: David Laight <david.laight@aculab.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-03-06 16:25:35 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: move global variables to local variables of main() I do not mind global variables where they are useful enough. In this case, I do not see a good reason to use global variables since they are just referenced in shallow places. It is easy to pass them via function arguments. I squashed print_cmdline() into main() since it is just one line code. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:44 +09:00
fixdep: factor out common code for reading files Now, do_config_files() and print_deps() are almost the same. Only the difference is the parser function called (parse_config_file vs parse_dep_file). We can reduce the code duplication by factoring out the common code into read_file() - this function allocates a buffer and loads a file to it. It returns the pointer to the allocated buffer. (As before, it bails out by exit(2) for any error.) The caller must free the buffer when done. Having empty source files is possible; fixdep should simply skip them. I deleted the "st.st_size == 0" check, so read_file() allocates 1-byte buffer for an empty file. strstr() will immediately return NULL, and this is what we expect. On the other hand, an empty dep_file should be treated as an error. In this case, parse_dep_file() will error out with "no targets found" and it is a correct error message. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:42 +09:00
kbuild: simplify dependency generation for CONFIG_TRIM_UNUSED_KSYMS My main motivation of this commit is to clean up scripts/Kbuild.include and scripts/Makefile.build. Currently, CONFIG_TRIM_UNUSED_KSYMS works with a tricky gimmick; possibly exported symbols are detected by letting $(CPP) replace EXPORT_SYMBOL* with a special string '=== __KSYM_*===', which is post-processed by sed, and passed to fixdep. The extra preprocessing is costly, and hacking cmd_and_fixdep is ugly. I came up with a new way to find exported symbols; insert a dummy symbol __ksym_marker_* to each potentially exported symbol. Those dummy symbols are picked up by $(NM), post-processed by sed, then appended to .*.cmd files. I collected the post-process part to a new shell script scripts/gen_ksymdeps.sh for readability. The dummy symbols are put into the .discard.* section so that the linker script rips them off the final vmlinux or modules. A nice side-effect is building with CONFIG_TRIM_UNUSED_KSYMS will be much faster. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Nicolas Pitre <nico@linaro.org>
2018-11-30 10:05:26 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: use fflush() and ferror() to ensure successful write to files Currently, fixdep checks the return value from (v)printf(), but it does not ensure the complete write to the .cmd file. printf() just writes data to the internal buffer, which usually succeeds. (Of course, it may fail for another reason, for example when the file descriptor is closed, but that is another story.) When the buffer (4k?) is full, an actual write occurs, and printf() may really fail. One of typical cases is "No space left on device" when the disk is full. The data remaining in the buffer will be pushed out to the file when the program exits, but we never know if it is successful. One straight-forward fix would be to add the following code at the end of the program. ret = fflush(stdout); if (ret < 0) { /* error handling */ } However, it is tedious to check the return code in all the call sites of printf(), fflush(), fclose(), and whatever can cause actual writes to the end device. Doing that lets the program bail out at the first failure but is usually not worth the effort. Instead, let's check the error status from ferror(). This is 'sticky', so you need to check it just once. You still need to call fflush(). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: David Laight <david.laight@aculab.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-03-06 16:25:35 +09:00
fixdep: factor out common code for reading files Now, do_config_files() and print_deps() are almost the same. Only the difference is the parser function called (parse_config_file vs parse_dep_file). We can reduce the code duplication by factoring out the common code into read_file() - this function allocates a buffer and loads a file to it. It returns the pointer to the allocated buffer. (As before, it bails out by exit(2) for any error.) The caller must free the buffer when done. Having empty source files is possible; fixdep should simply skip them. I deleted the "st.st_size == 0" check, so read_file() allocates 1-byte buffer for an empty file. strstr() will immediately return NULL, and this is what we expect. On the other hand, an empty dep_file should be treated as an error. In this case, parse_dep_file() will error out with "no targets found" and it is a correct error message. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:42 +09:00
kbuild: simplify dependency generation for CONFIG_TRIM_UNUSED_KSYMS My main motivation of this commit is to clean up scripts/Kbuild.include and scripts/Makefile.build. Currently, CONFIG_TRIM_UNUSED_KSYMS works with a tricky gimmick; possibly exported symbols are detected by letting $(CPP) replace EXPORT_SYMBOL* with a special string '=== __KSYM_*===', which is post-processed by sed, and passed to fixdep. The extra preprocessing is costly, and hacking cmd_and_fixdep is ugly. I came up with a new way to find exported symbols; insert a dummy symbol __ksym_marker_* to each potentially exported symbol. Those dummy symbols are picked up by $(NM), post-processed by sed, then appended to .*.cmd files. I collected the post-process part to a new shell script scripts/gen_ksymdeps.sh for readability. The dummy symbols are put into the .discard.* section so that the linker script rips them off the final vmlinux or modules. A nice side-effect is building with CONFIG_TRIM_UNUSED_KSYMS will be much faster. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Nicolas Pitre <nico@linaro.org>
2018-11-30 10:05:26 +09:00
fixdep: factor out common code for reading files Now, do_config_files() and print_deps() are almost the same. Only the difference is the parser function called (parse_config_file vs parse_dep_file). We can reduce the code duplication by factoring out the common code into read_file() - this function allocates a buffer and loads a file to it. It returns the pointer to the allocated buffer. (As before, it bails out by exit(2) for any error.) The caller must free the buffer when done. Having empty source files is possible; fixdep should simply skip them. I deleted the "st.st_size == 0" check, so read_file() allocates 1-byte buffer for an empty file. strstr() will immediately return NULL, and this is what we expect. On the other hand, an empty dep_file should be treated as an error. In this case, parse_dep_file() will error out with "no targets found" and it is a correct error message. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-01-11 22:05:42 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
fixdep: use fflush() and ferror() to ensure successful write to files Currently, fixdep checks the return value from (v)printf(), but it does not ensure the complete write to the .cmd file. printf() just writes data to the internal buffer, which usually succeeds. (Of course, it may fail for another reason, for example when the file descriptor is closed, but that is another story.) When the buffer (4k?) is full, an actual write occurs, and printf() may really fail. One of typical cases is "No space left on device" when the disk is full. The data remaining in the buffer will be pushed out to the file when the program exits, but we never know if it is successful. One straight-forward fix would be to add the following code at the end of the program. ret = fflush(stdout); if (ret < 0) { /* error handling */ } However, it is tedious to check the return code in all the call sites of printf(), fflush(), fclose(), and whatever can cause actual writes to the end device. Doing that lets the program bail out at the first failure but is usually not worth the effort. Instead, let's check the error status from ferror(). This is 'sticky', so you need to check it just once. You still need to call fflush(). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: David Laight <david.laight@aculab.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-03-06 16:25:35 +09:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00