10 Jul, 2019
3 commits
-
In old days, Kbuild always used an absolute path for $(srctree).
Since commit 890676c65d69 ("kbuild: Use relative path when building in
the source tree"), $(srctree) is '.' when O= was not passed from the
command line.Yet, using absolute paths is useful in some cases even without O=, for
instance, to create a cscope file with absolute path tags.'O=.' was known to work as a workaround to force Kbuild to use absolute
paths even when you are building in the source tree.Since commit 25b146c5b8ce ("kbuild: allow Kbuild to start from any
directory"), Kbuild is too clever to be tricked. Even if you pass 'O=.'
Kbuild notices you are building in the source tree, then use '.' for
$(srctree).So, 'make O=. cscope' is no help to create absolute path tags.
We cannot force one or the other according to commit e93bc1a0cab3
("Revert "kbuild: specify absolute paths for cscope""). Both of
relative path and absolute path have pros and cons.This commit adds a new flag KBUILD_ABS_SRCTREE to allow users to
choose the absolute path for $(srctree).'make KBUILD_ABS_SRCTREE=1 cscope' will work as a replacement of
'make O=. cscope'.Reported-by: Pawan Gupta
Signed-off-by: Masahiro Yamada -
Commit 25b146c5b8ce ("kbuild: allow Kbuild to start from any directory")
deprecated KBUILD_SRCTREE.It is only used in tools/testing/selftest/ to distinguish out-of-tree
build. Replace it with a new boolean flag, building_out_of_srctree.I also replaced the conditional ($(srctree),.) because the next commit
will allow an absolute path to be used for $(srctree) even when building
in the source tree.Signed-off-by: Masahiro Yamada
-
Replace $(src) and $(obj) with $(srctree) and $(objtree), respectively.
Signed-off-by: Masahiro Yamada
09 Jul, 2019
7 commits
-
This script has no reference to ${ARCH}, ${src}, ${obj}.
Signed-off-by: Masahiro Yamada
-
Our goal is to have more and more sub-architectures to join the
ARM multi-platform, and support them in a single configuration.Remove the ARM SUBARCH support because it is ugly.
Signed-off-by: Masahiro Yamada
-
The headers in include/ are globally used in the kernel source tree
to provide common APIs. They are included from external modules, too.It will be useful to make as many headers self-contained as possible
so that we do not have to rely on a specific include order.There are more than 4000 headers in include/. In my rough analysis,
70% of them are already self-contained. With efforts, most of them
can be self-contained.For now, we must exclude more than 1000 headers just because they
cannot be compiled as standalone units. I added them to header-test-.
The blacklist was mostly generated by a script, so the reason of the
breakage should be checked later.Signed-off-by: Masahiro Yamada
Tested-by: Jani Nikula
Reviewed-by: Joel Fernandes (Google) -
Currently, kheaders_data.tar.xz contains some build scripts as well as
headers. None of them is needed in the header archive.For ARCH=x86, this commit excludes the following from the archive:
arch/x86/include/asm/Kbuild
arch/x86/include/uapi/asm/Kbuild
include/asm-generic/Kbuild
include/config/auto.conf
include/config/kernel.release
include/config/tristate.conf
include/uapi/asm-generic/Kbuild
include/uapi/Kbuild
kernel/gen_kheaders.shThis change is actually motivated for the planned header compile-testing
because it will generate more build artifacts, which should not be
included in the archive.Signed-off-by: Masahiro Yamada
Reviewed-by: Joel Fernandes (Google) -
The -R option of 'ls' is supposed to be used for directories.
-R, --recursive
list subdirectories recursivelySince 'find ... -type f' only matches to regular files, we do not
expect directories passed to the 'ls' command here.Giving -R is harmless at least, but unneeded.
Signed-off-by: Masahiro Yamada
Reviewed-by: Joel Fernandes (Google) -
In my view, most of headers can be self-contained. So, it would be
tedious to add every header to header-test-y explicitly. We usually
end up with "all headers with some exceptions".There are two types in exceptions:
[1] headers that are never compiled as standalone units
For examples, include/linux/compiler-gcc.h is not intended for
direct inclusion. We should always exclude such ones.[2] headers that are conditionally compiled as standalone units
Some headers can be compiled only for particular architectures.
For example, include/linux/arm-cci.h can be compiled only for
arm/arm64 because it requires to exist.
Clang can compile include/soc/nps/mtm.h only for arc because
it contains an arch-specific register in inline assembler.So, you can write Makefile like this:
header-test- += linux/compiler-gcc.h
header-test-$(CONFIG_ARM) += linux/arm-cci.h
header-test-$(CONFIG_ARM64) += linux/arm-cci.h
header-test-$(CONFIG_ARC) += soc/nps/mtm.hThe new syntax header-test-pattern-y will be useful to specify
"the rest".The typical usage is like this:
header-test-pattern-y += */*.h
This will add all the headers in sub-directories to the test coverage,
excluding $(header-test-). In this regards, header-test-pattern-y
behaves like a weaker variant of header-test-y.Caveat:
The patterns in header-test-pattern-y are prefixed with $(srctree)/$(src)/
but not $(objtree)/$(obj)/. Stale generated headers are often left over
when you traverse the git history without cleaning. Wildcard patterns for
$(objtree) may match to stale headers, which could fail to compile.
One pitfall is $(srctree)/$(src)/ and $(objtree)/$(obj)/ point to the
same directory for in-tree building. So, header-test-pattern-y should
be used with care since it can potentially match to stale headers.Caveat2:
You could use wildcard for header-test-. For example,header-test- += asm-generic/%
... will exclude headers in asm-generic directory. Unfortunately, the
wildcard character is '%' instead of '*' here because this is evaluated
by $(filter-out ...) whereas header-test-pattern-y is evaluated by
$(wildcard ...). This is a kludge, but seems useful in some places...Signed-off-by: Masahiro Yamada
Tested-by: Jani Nikula -
header-test-y does not work with headers in sub-directories.
For example, you may want to write a Makefile, like this:
include/linux/Kbuild:
header-test-y += mtd/nand.h
This entry will create a wrapper include/linux/mtd/nand.hdrtest.c
with the following content:#include "mtd/nand.h"
To make this work, we need to add $(srctree)/include/linux to the
header search path. It would be tedious to add ccflags-y.Instead, we could change the *.hdrtest.c rule to wrap:
#include "nand.h"
This works for in-tree build since #include "..." searches in the
relative path from the header with this directive. For O=... build,
we need to add $(srctree)/include/linux/mtd to the header search path,
which will be even more tedious.After all, I thought it would be handier to compile headers directly
without creating wrappers.I added a new build rule to compile %.h into %.h.s
The target is %.h.s instead of %.h.o because it is slightly faster.
Also, as for GCC, an empty assembly is smaller than an empty object.I wrote the build rule:
$(CC) $(c_flags) -S -o $@ -x c /dev/null -include $<
instead of:
$(CC) $(c_flags) -S -o $@ -x c $<
Both work fine with GCC, but the latter is bad for Clang.
This comes down to the difference in the -Wunused-function policy.
GCC does not warn about unused 'static inline' functions at all.
Clang does not warn about the ones in included headers, but does
about the ones in the source. So, we should handle headers as
headers, not as source files.In fact, this has been hidden since commit abb2ea7dfd82 ("compiler,
clang: suppress warning for unused static inline functions"), but we
should not rely on that.Signed-off-by: Masahiro Yamada
Acked-by: Jani Nikula
Tested-by: Jani Nikula
08 Jul, 2019
8 commits
-
Multiple people have suggested compile-testing UAPI headers to ensure
they can be really included from user-space. "make headers_check" is
obviously not enough to catch bugs, and we often leak unresolved
references to user-space.Use the new header-test-y syntax to implement it. Please note exported
headers are compile-tested with a completely different set of compiler
flags. The header search path is set to $(objtree)/usr/include since
exported headers should not include unexported ones.We use -std=gnu89 for the kernel space since the kernel code highly
depends on GNU extensions. On the other hand, UAPI headers should be
written in more standardized C, so they are compiled with -std=c90.
This will emit errors if C++ style comments, the keyword 'inline', etc.
are used. Please use C style comments (/* ... */), '__inline__', etc.
in UAPI headers.There is additional compiler requirement to enable this test because
many of UAPI headers include , , ,
etc. directly or indirectly. You cannot use kernel.org pre-built
toolchains [1] since they lack .I reused CONFIG_CC_CAN_LINK to check the system header availability.
The intention is slightly different, but a compiler that can link
userspace programs provide system headers.For now, a lot of headers need to be excluded because they cannot
be compiled standalone, but this is a good start point.[1] https://mirrors.edge.kernel.org/pub/tools/crosstool/index.html
Signed-off-by: Masahiro Yamada
Reviewed-by: Sam Ravnborg -
Currently, scripts/cc-can-link.sh is run just for BPFILTER_UMH, but
defining CC_CAN_LINK will be useful in other places.Signed-off-by: Masahiro Yamada
-
gcc asan instrumentation emits the following sequence to store frame pc
when the kernel is built with CONFIG_RELOCATABLE:
debug/vsprintf.s:
.section .data.rel.ro.local,"aw"
.align 8
.LC3:
.quad .LASANPC4826@GOTOFF
.text
.align 8
.type number, @function
number:
.LASANPC4826:and in case reloc is issued for LASANPC label it also gets into .symtab
with the same address as actual function symbol:
$ nm -n vmlinux | grep 0000000001397150
0000000001397150 t .LASANPC4826
0000000001397150 t numberIn the end kernel backtraces are almost unreadable:
[ 143.748476] Call Trace:
[ 143.748484] ([] .LASANPC2671+0x114/0x190)
[ 143.748492] [] .LASANPC2612+0x110/0x160
[ 143.748502] [] print_address_description+0x80/0x3b0
[ 143.748511] [] __kasan_report+0x15c/0x1c8
[ 143.748521] [] strrchr+0x34/0x60
[ 143.748534] [] kasan_strings+0xb0/0x148 [test_kasan]
[ 143.748547] [] kmalloc_tests_init+0xe2/0x528 [test_kasan]
[ 143.748555] [] .LASANPC4069+0x354/0x748
[ 143.748563] [] do_init_module+0x136/0x3b0
[ 143.748571] [] .LASANPC3191+0x2164/0x25d0
[ 143.748580] [] .LASANPC3196+0x184/0x1b8
[ 143.748587] [] system_call+0xd8/0x2d8Since LASANPC labels are not even unique and get into .symtab only due
to relocs filter them out in kallsyms.Signed-off-by: Vasily Gorbik
Signed-off-by: Masahiro Yamada -
Commit 0126be38d988 ("kbuild: announce removal of SUBDIRS if used")
added a hint about the 'SUBDIRS' replacement, but it was not clear
enough.Multiple people sent me similar questions, patches. For instance,
https://lkml.org/lkml/2019/1/17/456
I did not mean to use M= for building a subdirectory in the kernel tree.
From commit 669efc76b317 ("net: hns3: fix compile error"), people
already (ab)use M=... to do that because it seems to work to some extent.Documentation/kbuild/kbuild.txt says M= and KBUILD_EXTMOD are used for
building external modules.In fact, Kbuild supports the single target '%/' for this purpose, but
this may not be noticed much.Kindly add more hints.
Makefile:213: ================= WARNING ================
Makefile:214: 'SUBDIRS' will be removed after Linux 5.3
Makefile:215:
Makefile:216: If you are building an individual subdirectory
Makefile:217: in the kernel tree, you can do like this:
Makefile:218: $ make path/to/dir/you/want/to/build/
Makefile:219: (Do not forget the trailing slash)
Makefile:220:
Makefile:221: If you are building an external module,
Makefile:222: Please use 'M=' or 'KBUILD_EXTMOD' instead
Makefile:223: ==========================================Suggested-by: Christoph Hellwig
Signed-off-by: Masahiro Yamada
Acked-by: Sam Ravnborg -
Previously steam_open.cocci was treating only wait_event_.* - e.g.
wait_event_interruptible - as a blocking operation. However e.g.
wait_for_completion_interruptible is also blocking, and so from this
point of view it would be more logical to treat all wait_.* as a
blocking point.The logic of this change actually came up for real when
drivers/pci/switch/switchtec.c changed from using
wait_event_interruptible to wait_for_completion_interruptible:https://lore.kernel.org/linux-pci/20190413170056.GA11293@deco.navytux.spb.ru/
https://lore.kernel.org/linux-pci/20190415145456.GA15280@deco.navytux.spb.ru/
https://lore.kernel.org/linux-pci/20190415154102.GB17661@deco.navytux.spb.ru/For a driver that uses nonseekable_open with read/write having stream
semantic and read also calling e.g. wait_for_completion_interruptible,
running stream_open.cocci before this patch would produce:WARNING: _fops: .read() and .write() have stream semantic; safe to change nonseekable_open -> stream_open.
while after this patch it will report:
ERROR: _fops: .read() can deadlock .write(); change nonseekable_open -> stream_open to fix.
Signed-off-by: Kirill Smelkov
Acked-by: Julia Lawall
Signed-off-by: Masahiro Yamada -
Extend a when constraint in a SmPL rule so that an additional cast
is optionally excluded from source code searches for an expression
in assignments.Signed-off-by: Markus Elfring
Suggested-by: Julia Lawall
Link: https://lore.kernel.org/lkml/alpine.DEB.2.21.1902160934400.3212@hadrien/
Link: https://systeme.lip6.fr/pipermail/cocci/2019-February/005592.html
Acked-by: Julia Lawall
Signed-off-by: Masahiro Yamada -
The Linux coding style tolerates long string literals so that
the provided information can be easier found also by search tools
like grep.
Thus simplify a message construction in a SmPL rule by concatenating text
with two plus operators less.Signed-off-by: Markus Elfring
Signed-off-by: Masahiro Yamada -
Replace 'kstrdep' with 'kstrdup' in warning messages.
Signed-off-by: Rikard Falkeborn
Acked-by: Julia Lawall
Signed-off-by: Masahiro Yamada
04 Jul, 2019
1 commit
-
There are some people interested in experimenting with Clang's
integrated assembler. To make it easy to do so without source
modification, allow the user to specify 'AS=clang' as part of the
make command to avoid adding '-no-integrated-as' to the {A,C}FLAGS.Link: https://github.com/ClangBuiltLinux/linux/issues/577
Suggested-by: Dmitry Golovin
Signed-off-by: Nathan Chancellor
Reviewed-by: Nick Desaulniers
Tested-by: Nick Desaulniers
Signed-off-by: Masahiro Yamada
01 Jul, 2019
6 commits
-
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
-
modules.order is a real target. Split its build rule out like
modules.builtinSigned-off-by: Masahiro Yamada
-
Unlike modules.order, modules.builtin is not rebuilt every time.
Once modules.builtin is created, it will not be updated until
auto.conf or tristate.conf is changed.So, it does not notice a change in Makefile, for example, the rename
of modules.Kbuild must always descend into directories for modules.builtin too.
Signed-off-by: Masahiro Yamada
-
The string returned by $(filter-out ...) does not contain any leading
or trailing spaces.With the previous commit, 'any-prereq' no longer contains any
excessive spaces.Nor does 'cmd-check' since it expands to a $(filter-out ...) call.
So, only the space that matters is the one between 'any-prereq'
and 'cmd-check'.By removing it from the code, we can save $(strip ...) evaluation.
This refactoring is possible because $(any-prereq)$(cmd-check) is only
passed to the first argument of $(if ...), so we are only interested
in whether or not it is empty.Signed-off-by: Masahiro Yamada
-
The string returned by $(filter-out ...) does not contain any leading
or trailing spaces.So, only the space that matters is the one between
$(filter-out $(PHONY),$?)
and
$(filter-out $(PHONY) $(wildcard $^),$^)
By removing it from the code, we can save $(strip ...) evaluation.
This refactoring is possible because $(any-prereq) is only passed to
the first argument of $(if ...), so we are only interested in whether
or not it is empty.This is also the prerequisite for the next commit.
Signed-off-by: Masahiro Yamada
-
I prefer 'cmd-check' for consistency.
We have 'echo-cmd', 'cmd', 'cmd_and_fixdep', etc. in this file.
Signed-off-by: Masahiro Yamada
24 Jun, 2019
7 commits
-
Since commit d5470d14431e ("kbuild: re-implement Makefile.headersinst
without recursion"), headers_install emits an ugly warning.$ make headers_install
[ snip ]
UPD include/generated/uapi/linux/version.h
find: ‘./include/uapi/Kbuild’: No such file or directory
HDRINST usr/include/video/uvesafb.h
...This happens for GNU Make
| Date: Wed Jun 20 02:03:48 2018 +0300
|
| * src/dir.c: Preserve glob d_type fieldWe need to cater to old Make versions. Add '$(filter %/,...) to filter
out the regular files.Fixes: d5470d14431e ("kbuild: re-implement Makefile.headersinst without recursion")
Signed-off-by: Masahiro Yamada -
__uint128_t crops up in a few files that export symbols to modules, so
teach genksyms about it and the other GCC built-in 128-bit integer types
so that we don't end up skipping the CRC generation for some symbols due
to the parser failing to spot them:| WARNING: EXPORT symbol "kernel_neon_begin" [vmlinux] version
| generation failed, symbol will not be versioned.
| ld: arch/arm64/kernel/fpsimd.o: relocation R_AARCH64_ABS32 against
| `__crc_kernel_neon_begin' can not be used when making a shared
| object
| ld: arch/arm64/kernel/fpsimd.o:(.data+0x0): dangerous relocation:
| unsupported relocationReported-by: Arnd Bergmann
Signed-off-by: Will Deacon
Signed-off-by: Masahiro Yamada -
This flag turns off several other warnings that would
be useful. Most notably -warn_unused_result is disabled.
All of the following warnings are currently disabled:UnusedValue
|-UnusedComparison
|-warn_unused_comparison
|-UnusedResult
|-warn_unused_result
|-UnevaluatedExpression
|-PotentiallyEvaluatedExpression
|-warn_side_effects_typeid
|-warn_side_effects_unevaluated_context
|-warn_unused_expr
|-warn_unused_voidptr
|-warn_unused_container_subscript_expr
|-warn_unused_callWith this flag removed there are ~10 warnings.
Patches have been submitted for each of these warnings.Reported-by: Nick Desaulniers
Cc: clang-built-linux@googlegroups.com
Link: https://github.com/ClangBuiltLinux/linux/issues/520
Signed-off-by: Nathan Huckleberry
Reviewed-by: Nick Desaulniers
Signed-off-by: Masahiro Yamada -
This Makefile repeats very similar rules.
Let's use pattern rules. $(UNROLL) can be replaced with $*.
No intended change in behavior.
Signed-off-by: Masahiro Yamada
-
No intended change in behavior.
Signed-off-by: Masahiro Yamada
-
This helps fine very dodgy behavior through both -Wuninitialized
(warning that a variable is always uninitialized) and
-Wsometimes-uninitialized (warning that a variable is sometimes
uninitialized, like GCC's -Wmaybe-uninitialized). These warnings
catch things that GCC doesn't such as:https://lore.kernel.org/lkml/86649ee4-9794-77a3-502c-f4cd10019c36@lca.pw/
We very much want to catch these so turn this warning on so that CI is
aware of it.Link: https://github.com/ClangBuiltLinux/linux/issues/381
Signed-off-by: Nathan Chancellor
Reviewed-by: Nick Desaulniers
Signed-off-by: Masahiro Yamada -
In commit ebcc5928c5d9 ("arm64: Silence gcc warnings about arch ABI
drift"), the arm64 Makefile added -Wno-psabi to KBUILD_CFLAGS, which is
a GCC only option so clang rightfully complains:warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option]
https://clang.llvm.org/docs/DiagnosticsReference.html#wunknown-warning-option
However, by default, this is merely a warning so the build happily goes
on with a slew of these warnings in the process.Commit c3f0d0bc5b01 ("kbuild, LLVMLinux: Add -Werror to cc-option to
support clang") worked around this behavior in cc-option by adding
-Werror so that unknown flags cause an error. However, this all happens
silently and when an unknown flag is added to the build unconditionally
like -Wno-psabi, cc-option will always fail because there is always an
unknown flag in the list of flags. This manifested as link time failures
in the arm64 libstub because -fno-stack-protector didn't get added to
KBUILD_CFLAGS.To avoid these weird cryptic failures in the future, make clang behave
like gcc and immediately error when it encounters an unknown flag by
adding -Werror=unknown-warning-option to CLANG_FLAGS. This can be added
unconditionally for clang because it is supported by at least 3.0.0,
according to godbolt [1] and 4.0.0, according to its documentation [2],
which is far earlier than we typically support.[1]: https://godbolt.org/z/7F7rm3
[2]: https://releases.llvm.org/4.0.0/tools/clang/docs/DiagnosticsReference.html#wunknown-warning-optionLink: https://github.com/ClangBuiltLinux/linux/issues/511
Link: https://github.com/ClangBuiltLinux/linux/issues/517
Suggested-by: Peter Smith
Signed-off-by: Nathan Chancellor
Tested-by: Nick Desaulniers
Signed-off-by: Masahiro Yamada
15 Jun, 2019
8 commits
-
Sometimes it's useful to be able to explicitly ensure certain headers
remain self-contained, i.e. that they are compilable as standalone
units, by including and/or forward declaring everything they depend on.Add special target header-test-y where individual Makefiles can add
headers to be tested if CONFIG_HEADER_TEST is enabled. This will
generate a dummy C file per header that gets built as part of extra-y.Signed-off-by: Jani Nikula
Reviewed-by: Sam Ravnborg
Signed-off-by: Masahiro Yamada -
It is absolutely fine to add extra sanity checks in package scripts,
but it is not necessary to do so.This is already covered by the daily compile-testing (0day bot etc.)
because headers_check is run as a part of the normal build process
when CONFIG_HEADERS_CHECK=y.Replace it with the newly-added "make headers".
Signed-off-by: Masahiro Yamada
-
Now that headers_install.sh is invoked per file, remove the for-loop
in the shell script.Signed-off-by: Masahiro Yamada
-
Now that hdr-inst is used only in the top Makefile, move it there
from scripts/Kbuild.include.Signed-off-by: Masahiro Yamada
-
Since commit fcc8487d477a ("uapi: export all headers under uapi
directories"), the headers in uapi directories are all exported by
default although exceptional cases are still allowed by the syntax
'no-export-headers'.The traditional directory descending has been kept (in a somewhat
hacky way), but it is actually unneeded.Get rid of it to simplify the code.
Also, handle files one by one instead of the previous per-directory
processing. This will emit much more log, but I like it.Signed-off-by: Masahiro Yamada
-
In Linux build system, build targets and installation targets are
separated.Examples are:
- 'make vmlinux' -> 'make install'
- 'make modules' -> 'make modules_install'
- 'make dtbs' -> 'make dtbs_install'
- 'make vdso' -> 'make vdso_install'The intention is to run the build targets under the normal privilege,
then the installation targets under the root privilege since we need
the write permission to the system directories.We have 'make headers_install' but the corresponding 'make headers'
stage does not exist. The purpose of headers_install is to provide
the kernel interface to C library. So, nobody would try to install
headers to /usr/include directly.If 'sudo make INSTALL_HDR_PATH=/usr/include headers_install' were run,
some build artifacts in the kernel tree would be owned by root because
some of uapi headers are generated by 'uapi-asm-generic', 'archheaders'
targets.Anyway, I believe it makes sense to split the header installation into
two stages.[1] 'make headers'
Process headers in uapi directories by scripts/headers_install.sh
and copy them to usr/include[2] 'make headers_install'
Copy '*.h' verbatim from usr/include to $(INSTALL_HDR_PATH)/includeFor the backward compatibility, 'headers_install' depends on 'headers'.
Some samples expect uapi headers in usr/include. So, the 'headers'
target is useful to build up them in the fixed location usr/include
irrespective of INSTALL_HDR_PATH.Another benefit is to stop polluting the final destination with the
time-stamp files '.install' and '.check'. Maybe you can see them in
your toolchains.Lastly, my main motivation is to prepare for compile-testing uapi
headers. To build something, we have to save an object and .*.cmd
somewhere. The usr/include/ will be the work directory for that.Signed-off-by: Masahiro Yamada
-
Currently, scripts/unifdef is compiled after scripts_basic,
uapi-asm-generic, archheaders, and archscripts.The proper dependency is just scripts_basic. There is no problem
to compile scripts/unifdef and other headers at the same time.Split scripts_unifdef out in order to allow more parallel building.
Signed-off-by: Masahiro Yamada
-
Since commit 2aedcd098a94 ("kbuild: suppress annoying "... is up to date."
message"), if_changed and friends nicely suppress "is up to date" messages.We do not need per-Makefile tricks.
Signed-off-by: Masahiro Yamada
