summaryrefslogtreecommitdiff
path: root/Makefile
AgeCommit message (Collapse)AuthorFilesLines
2025-03-28Linux 6.13.9v6.13.9Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20250325122149.058346343@linuxfoundation.org Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Christian Heusel <christian@heusel.eu> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-22Linux 6.13.8v6.13.8Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20250319143027.685727358@linuxfoundation.org Tested-by: SeongJae Park <sj@kernel.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Hardik Garg <hargar@linux.microsoft.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-13Linux 6.13.7v6.13.7Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20250310170447.729440535@linuxfoundation.org Tested-by: SeongJae Park <sj@kernel.org> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-By: Achill Gilgenast <fossdd@pwned.life> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Hardik Garg <hargar@linux.microsoft.com> Link: https://lore.kernel.org/r/20250311144241.070217339@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Tested-by: Hardik Garg <hargar@linux.microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-13kbuild: userprogs: use correct lld when linking through clangThomas Weißschuh1-0/+5
commit dfc1b168a8c4b376fa222b27b97c2c4ad4b786e1 upstream. The userprog infrastructure links objects files through $(CC). Either explicitly by manually calling $(CC) on multiple object files or implicitly by directly compiling a source file to an executable. The documentation at Documentation/kbuild/llvm.rst indicates that ld.lld would be used for linking if LLVM=1 is specified. However clang instead will use either a globally installed cross linker from $PATH called ${target}-ld or fall back to the system linker, which probably does not support crosslinking. For the normal kernel build this is not an issue because the linker is always executed directly, without the compiler being involved. Explicitly pass --ld-path to clang so $(LD) is respected. As clang 13.0.1 is required to build the kernel, this option is available. Fixes: 7f3a59db274c ("kbuild: add infrastructure to build userspace programs") Cc: stable@vger.kernel.org # needs wrapping in $(cc-option) for < 6.9 Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-07Linux 6.13.6v6.13.6Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20250305174505.268725418@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: SeongJae Park <sj@kernel.org> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Hardik Garg <hargar@linux.microsoft.com> Link: https://lore.kernel.org/r/20250306151416.469067667@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-By: Achill Gilgenast <fossdd@pwned.life> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-27Linux 6.13.5v6.13.5Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20250224142604.442289573@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: FLorian Fainelli <florian.fainelli@broadcom.com> Tested-by: Pavel Machek (CIP) <pavel@denx.de> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Tested-by: Ron Economos <re@w6rz.net> Link: https://lore.kernel.org/r/20250225064750.953124108@linuxfoundation.org Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Slade Watkins <srw@sladewatkins.net> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-By: Achill Gilgenast <fossdd@pwned.life> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Pavel Machek (CIP) <pavel@denx.de> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-21Linux 6.13.4v6.13.4Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20250219082609.533585153@linuxfoundation.org Tested-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Hardik Garg <hargar@linux.microsoft.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20250220104500.178420129@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Hardik Garg <hargar@linux.microsoft.com> Tested-by: Pavel Machek (CIP) <pavel@denx.de> Tested-by: Slade Watkins <srw@sladewatkins.net> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-By: Achill Gilgenast <fossdd@pwned.life> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-21kbuild: userprogs: fix bitsize and target detection on clangThomas Weißschuh1-2/+2
commit 1b71c2fb04e7a713abc6edde4a412416ff3158f2 upstream. scripts/Makefile.clang was changed in the linked commit to move --target from KBUILD_CFLAGS to KBUILD_CPPFLAGS, as that generally has a broader scope. However that variable is not inspected by the userprogs logic, breaking cross compilation on clang. Use both variables to detect bitsize and target arguments for userprogs. Fixes: feb843a469fb ("kbuild: add $(CLANG_FLAGS) to KBUILD_CPPFLAGS") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-21tools: fix annoying "mkdir -p ..." logs when building tools in parallelMasahiro Yamada1-7/+2
[ Upstream commit d1d0963121769d8d16150b913fe886e48efefa51 ] When CONFIG_OBJTOOL=y or CONFIG_DEBUG_INFO_BTF=y, parallel builds show awkward "mkdir -p ..." logs. $ make -j16 [ snip ] mkdir -p /home/masahiro/ref/linux/tools/objtool && make O=/home/masahiro/ref/linux subdir=tools/objtool --no-print-directory -C objtool mkdir -p /home/masahiro/ref/linux/tools/bpf/resolve_btfids && make O=/home/masahiro/ref/linux subdir=tools/bpf/resolve_btfids --no-print-directory -C bpf/resolve_btfids Defining MAKEFLAGS=<value> on the command line wipes out command line switches from the resultant MAKEFLAGS definition, even though the command line switches are active. [1] MAKEFLAGS puts all single-letter options into the first word, and that word will be empty if no single-letter options were given. [2] However, this breaks if MAKEFLAGS=<value> is given on the command line. The tools/ and tools/% targets set MAKEFLAGS=<value> on the command line, which breaks the following code in tools/scripts/Makefile.include: short-opts := $(firstword -$(MAKEFLAGS)) If MAKEFLAGS really needs modification, it should be done through the environment variable, as follows: MAKEFLAGS=<value> $(MAKE) ... That said, I question whether modifying MAKEFLAGS is necessary here. The only flag we might want to exclude is --no-print-directory, as the tools build system changes the working directory. However, people might find the "Entering/Leaving directory" logs annoying. I simply removed the offending MAKEFLAGS=<value>. [1]: https://savannah.gnu.org/bugs/?62469 [2]: https://www.gnu.org/software/make/manual/make.html#Testing-Flags Fixes: ea01fa9f63ae ("tools: Connect to the kernel build system") Fixes: a50e43332756 ("perf tools: Honor parallel jobs") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Daniel Xu <dxu@dxuuu.xyz> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-17Linux 6.13.3v6.13.3Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20250213142440.609878115@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Pavel Machek (CIP) <pavel@denx.de> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Hardik Garg <hargar@linux.microsoft.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Luna Jernberg <droidbittin@gmail.com> Link: https://lore.kernel.org/r/20250214133842.964440150@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Slade Watkins <srw@sladewatkins.net> Tested-by: Hardik Garg <hargar@linux.microsoft.com> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250215075925.888236411@linuxfoundation.org Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Slade Watkins <srw@sladewatkins.net> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Pavel Machek (CIP) <pavel@denx.de> Tested-by: Kexy Biscuit <kexybiscuit@aosc.io> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-08Linux 6.13.2v6.13.2Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20250205134456.221272033@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Pavel Machek (CIP) <pavel@denx.de> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Tested-by: Hardik Garg <hargar@linux.microsoft.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Christian Heusel <christian@heusel.eu> Link: https://lore.kernel.org/r/20250206160718.019272260@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Jiri Slaby <jirislaby@kernel.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Pavel Machek (CIP) <pavel@denx.de> Tested-By: Achill Gilgenast <fossdd@pwned.life> Tested-by: Hardik Garg <hargar@linux.microsoft.com> Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-01Linux 6.13.1v6.13.1Greg Kroah-Hartman1-1/+1
Link: https://lore.kernel.org/r/20250130133456.914329400@linuxfoundation.org Tested-by: Ronald Warsow <rwarsow@gmx.de> Tested-by: Luna Jernberg <droidbittin@gmail.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Christian Heusel <christian@heusel.eu> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Justin M. Forbes <jforbes@fedoraproject.org> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: kernelci.org bot <bot@kernelci.org> Tested-by: Kexy Biscuit <kexybiscuit@aosc.io> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-19Linux 6.13v6.13Linus Torvalds1-1/+1
2025-01-12Linux 6.13-rc7v6.13-rc7Linus Torvalds1-1/+1
2025-01-05Linux 6.13-rc6v6.13-rc6Linus Torvalds1-1/+1
2024-12-29Linux 6.13-rc5v6.13-rc5Linus Torvalds1-1/+1
2024-12-22Linux 6.13-rc4v6.13-rc4Linus Torvalds1-1/+1
2024-12-15Linux 6.13-rc3v6.13-rc3Linus Torvalds1-1/+1
2024-12-08Linux 6.13-rc2v6.13-rc2Linus Torvalds1-1/+1
2024-12-01Linux 6.13-rc1v6.13-rc1Linus Torvalds1-2/+2
2024-11-30Merge tag 'kbuild-v6.13' of ↵Linus Torvalds1-86/+137
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild updates from Masahiro Yamada: - Add generic support for built-in boot DTB files - Enable TAB cycling for dialog buttons in nconfig - Fix issues in streamline_config.pl - Refactor Kconfig - Add support for Clang's AutoFDO (Automatic Feedback-Directed Optimization) - Add support for Clang's Propeller, a profile-guided optimization. - Change the working directory to the external module directory for M= builds - Support building external modules in a separate output directory - Enable objtool for *.mod.o and additional kernel objects - Use lz4 instead of deprecated lz4c - Work around a performance issue with "git describe" - Refactor modpost * tag 'kbuild-v6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (85 commits) kbuild: rename .tmp_vmlinux.kallsyms0.syms to .tmp_vmlinux0.syms gitignore: Don't ignore 'tags' directory kbuild: add dependency from vmlinux to resolve_btfids modpost: replace tdb_hash() with hash_str() kbuild: deb-pkg: add python3:native to build dependency genksyms: reduce indentation in export_symbol() modpost: improve error messages in device_id_check() modpost: rename alias symbol for MODULE_DEVICE_TABLE() modpost: rename variables in handle_moddevtable() modpost: move strstarts() to modpost.h modpost: convert do_usb_table() to a generic handler modpost: convert do_of_table() to a generic handler modpost: convert do_pnp_device_entry() to a generic handler modpost: convert do_pnp_card_entries() to a generic handler modpost: call module_alias_printf() from all do_*_entry() functions modpost: pass (struct module *) to do_*_entry() functions modpost: remove DEF_FIELD_ADDR_VAR() macro modpost: deduplicate MODULE_ALIAS() for all drivers modpost: introduce module_alias_printf() helper modpost: remove unnecessary check in do_acpi_entry() ...
2024-11-28kbuild: switch from lz4c to lz4 for compressionParth Pancholi1-1/+1
Replace lz4c with lz4 for kernel image compression. Although lz4 and lz4c are functionally similar, lz4c has been deprecated upstream since 2018. Since as early as Ubuntu 16.04 and Fedora 25, lz4 and lz4c have been packaged together, making it safe to update the requirement from lz4c to lz4. Consequently, some distributions and build systems, such as OpenEmbedded, have fully transitioned to using lz4. OpenEmbedded core adopted this change in commit fe167e082cbd ("bitbake.conf: require lz4 instead of lz4c"), causing compatibility issues when building the mainline kernel in the latest OpenEmbedded environment, as seen in the errors below. This change also updates the LZ4 compression commands to make it backward compatible by replacing stdin and stdout with the '-' option, due to some unclear reason, the stdout keyword does not work for lz4 and '-' works for both. In addition, this modifies the legacy '-c1' with '-9' which is also compatible with both. This fixes the mainline kernel build failures with the latest master OpenEmbedded builds associated with the mentioned compatibility issues. LZ4 arch/arm/boot/compressed/piggy_data /bin/sh: 1: lz4c: not found ... ... ERROR: oe_runmake failed Link: https://github.com/lz4/lz4/pull/553 Suggested-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Parth Pancholi <parth.pancholi@toradex.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-11-28kbuild: remove support for single %.symtypes build ruleMasahiro Yamada1-1/+1
This rule is unnecessary because you can generate foo/bar.symtypes as a side effect using: $ make KBUILD_SYMTYPES=1 foo/bar.o While compiling *.o is slower than preprocessing, the impact is negligible. I prioritize keeping the code simpler. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2024-11-28kbuild: allow to start building external modules in any directoryMasahiro Yamada1-2/+6
Unless an explicit O= option is provided, external module builds must start from the kernel directory. This can be achieved by using the -C option: $ make -C /path/to/kernel M=/path/to/external/module This commit allows starting external module builds from any directory, so you can also do the following: $ make -f /path/to/kernel/Makefile M=/path/to/external/module The key difference is that the -C option changes the working directory and parses the Makefile located there, while the -f option only specifies the Makefile to use. As shown in the examples in Documentation/kbuild/modules.rst, external modules usually have a wrapper Makefile that allows you to build them without specifying any make arguments. The Makefile typically contains a rule as follows: KDIR ?= /path/to/kernel default: $(MAKE) -C $(KDIR) M=$(CURDIR) $(MAKECMDGOALS) The log will appear as follows: $ make make -C /path/to/kernel M=/path/to/external/module make[1]: Entering directory '/path/to/kernel' make[2]: Entering directory '/path/to/external/module' CC [M] helloworld.o MODPOST Module.symvers CC [M] helloworld.mod.o CC [M] .module-common.o LD [M] helloworld.ko make[2]: Leaving directory '/path/to/external/module' make[1]: Leaving directory '/path/to/kernel' This changes the working directory twice because the -C option first switches to the kernel directory, and then Kbuild internally recurses back to the external module directory. With this commit, the wrapper Makefile can directly include the kernel Makefile: KDIR ?= /path/to/kernel export KBUILD_EXTMOD := $(realpath $(dir $(lastword $(MAKEFILE_LIST)))) include $(KDIR)/Makefile This avoids unnecessary sub-make invocations: $ make CC [M] helloworld.o MODPOST Module.symvers CC [M] helloworld.mod.o CC [M] .module-common.o LD [M] helloworld.ko Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2024-11-28kbuild: make wrapper Makefile more convenient for external modulesMasahiro Yamada1-1/+11
When Kbuild starts building in a separate output directory, it generates a wrapper Makefile, allowing you to invoke 'make' from the output directory. This commit makes it more convenient, so you can invoke 'make' without M= or MO=. First, you need to build external modules in a separate directory: $ make M=/path/to/module/source/dir MO=/path/to/module/build/dir Once the wrapper Makefile is generated in /path/to/module/build/dir, you can proceed as follows: $ cd /path/to/module/build/dir $ make Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2024-11-28kbuild: use absolute path in the generated wrapper MakefileMasahiro Yamada1-2/+3
Keep the consistent behavior when this Makefile is invoked from another directory. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2024-11-28kbuild: support -fmacro-prefix-map for external modulesMasahiro Yamada1-2/+4
This commit makes -fmacro-prefix-map work for external modules built in a separate output directory. It improves the reproducibility of external modules and provides the benefits described in commit a73619a845d5 ("kbuild: use -fmacro-prefix-map to make __FILE__ a relative path"). When building_out_of_srctree is not defined (e.g., when the kernel or external module is built in the source directory), this option is unnecessary. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2024-11-28kbuild: support building external modules in a separate build directoryMasahiro Yamada1-2/+18
There has been a long-standing request to support building external modules in a separate build directory. This commit introduces a new environment variable, KBUILD_EXTMOD_OUTPUT, and its shorthand Make variable, MO. A simple usage: $ make -C <kernel-dir> M=<module-src-dir> MO=<module-build-dir> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2024-11-28kbuild: remove extmod_prefix, MODORDER, MODULES_NSDEPS variablesMasahiro Yamada1-13/+9
With the previous changes, $(extmod_prefix), $(MODORDER), and $(MODULES_NSDEPS) are constant. (empty, modules.order, and modules.nsdeps, respectively). Remove these variables and hard-code their values. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2024-11-28kbuild: change working directory to external module directory with M=Masahiro Yamada1-33/+49
Currently, Kbuild always operates in the output directory of the kernel, even when building external modules. This increases the risk of external module Makefiles attempting to write to the kernel directory. This commit switches the working directory to the external module directory, allowing the removal of the $(KBUILD_EXTMOD)/ prefix from some build artifacts. The command for building external modules maintains backward compatibility, but Makefiles that rely on working in the kernel directory may break. In such cases, $(objtree) and $(srctree) should be used to refer to the output and source directories of the kernel. The appearance of the build log will change as follows: [Before] $ make -C /path/to/my/linux M=/path/to/my/externel/module make: Entering directory '/path/to/my/linux' CC [M] /path/to/my/externel/module/helloworld.o MODPOST /path/to/my/externel/module/Module.symvers CC [M] /path/to/my/externel/module/helloworld.mod.o CC [M] /path/to/my/externel/module/.module-common.o LD [M] /path/to/my/externel/module/helloworld.ko make: Leaving directory '/path/to/my/linux' [After] $ make -C /path/to/my/linux M=/path/to/my/externel/module make: Entering directory '/path/to/my/linux' make[1]: Entering directory '/path/to/my/externel/module' CC [M] helloworld.o MODPOST Module.symvers CC [M] helloworld.mod.o CC [M] .module-common.o LD [M] helloworld.ko make[1]: Leaving directory '/path/to/my/externel/module' make: Leaving directory '/path/to/my/linux' Printing "Entering directory" twice is cumbersome. This will be addressed later. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de>
2024-11-27Merge tag 'modules-6.13-rc1' of ↵Linus Torvalds1-5/+1
git://git.kernel.org/pub/scm/linux/kernel/git/modules/linux Pull modules updates from Luis Chamberlain: - The whole caching of module code into huge pages by Mike Rapoport is going in through Andrew Morton's tree due to some other code dependencies. That's really the biggest highlight for Linux kernel modules in this release. With it we share huge pages for modules, starting off with x86. Expect to see that soon through Andrew! - Helge Deller addressed some lingering low hanging fruit alignment enhancements by. It is worth pointing out that from his old patch series I dropped his vmlinux.lds.h change at Masahiro's request as he would prefer this to be specified in asm code [0]. [0] https://lore.kernel.org/all/20240129192644.3359978-5-mcgrof@kernel.org/T/#m9efef5e700fbecd28b7afb462c15eed8ba78ef5a - Matthew Maurer and Sami Tolvanen have been tag teaming to help get us closer to a modversions for Rust. In this cycle we take in quite a lot of the refactoring for ELF validation. I expect modversions for Rust will be merged by v6.14 as that code is mostly ready now. - Adds a new modules selftests: kallsyms which helps us tests find_symbol() and the limits of kallsyms on Linux today. - We have a realtime mailing list to kernel-ci testing for modules now which relies and combines patchwork, kpd and kdevops: https://patchwork.kernel.org/project/linux-modules/list/ https://github.com/linux-kdevops/kdevops/blob/main/docs/kernel-ci/README.md https://github.com/linux-kdevops/kdevops/blob/main/docs/kernel-ci/kernel-ci-kpd.md https://github.com/linux-kdevops/kdevops/blob/main/docs/kernel-ci/linux-modules-kdevops-ci.md If you want to help avoid Linux kernel modules regressions, now its simple, just add a new Linux modules sefltests under tools/testing/selftests/module/ That is it. All new selftests will be used and leveraged automatically by the CI. * tag 'modules-6.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/modules/linux: tests/module/gen_test_kallsyms.sh: use 0 value for variables scripts: Remove export_report.pl selftests: kallsyms: add MODULE_DESCRIPTION selftests: add new kallsyms selftests module: Reformat struct for code style module: Additional validation in elf_validity_cache_strtab module: Factor out elf_validity_cache_strtab module: Group section index calculations together module: Factor out elf_validity_cache_index_str module: Factor out elf_validity_cache_index_sym module: Factor out elf_validity_cache_index_mod module: Factor out elf_validity_cache_index_info module: Factor out elf_validity_cache_secstrings module: Factor out elf_validity_cache_sechdrs module: Factor out elf_validity_ehdr module: Take const arg in validate_section_offset modules: Add missing entry for __ex_table modules: Ensure 64-bit alignment on __ksymtab_* sections
2024-11-27kbuild: use 'output' variable to create the output directoryMasahiro Yamada1-6/+8
$(KBUILD_OUTPUT) specifies the output directory of kernel builds. Use a more generic name, 'output', to better reflect this code hunk in the context of external module builds. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2024-11-27kbuild: rename abs_objtree to abs_outputMasahiro Yamada1-5/+5
'objtree' refers to the top of the output directory of kernel builds. Rename abs_objtree to a more generic name, to better reflect its use in the context of external module builds. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2024-11-27kbuild: add $(objtree)/ prefix to some in-kernel build artifactsMasahiro Yamada1-5/+5
$(objtree) refers to the top of the output directory of kernel builds. This commit adds the explicit $(objtree)/ prefix to build artifacts needed for building external modules. This change has no immediate impact, as the top-level Makefile currently defines: objtree := . This commit prepares for supporting the building of external modules in a different directory. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2024-11-27kbuild: replace two $(abs_objtree) with $(CURDIR) in top MakefileMasahiro Yamada1-2/+2
Kbuild changes the working directory until it matches $(abs_objtree). When $(need-sub-make) is empty, $(abs_objtree) is the same as $(CURDIR). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de>
2024-11-27kbuild: Add Propeller configuration for kernel buildRong Xu1-0/+1
Add the build support for using Clang's Propeller optimizer. Like AutoFDO, Propeller uses hardware sampling to gather information about the frequency of execution of different code paths within a binary. This information is then used to guide the compiler's optimization decisions, resulting in a more efficient binary. The support requires a Clang compiler LLVM 19 or later, and the create_llvm_prof tool (https://github.com/google/autofdo/releases/tag/v0.30.1). This commit is limited to x86 platforms that support PMU features like LBR on Intel machines and AMD Zen3 BRS. Here is an example workflow for building an AutoFDO+Propeller optimized kernel: 1) Build the kernel on the host machine, with AutoFDO and Propeller build config CONFIG_AUTOFDO_CLANG=y CONFIG_PROPELLER_CLANG=y then $ make LLVM=1 CLANG_AUTOFDO_PROFILE=<autofdo_profile> “<autofdo_profile>” is the profile collected when doing a non-Propeller AutoFDO build. This step builds a kernel that has the same optimization level as AutoFDO, plus a metadata section that records basic block information. This kernel image runs as fast as an AutoFDO optimized kernel. 2) Install the kernel on test/production machines. 3) Run the load tests. The '-c' option in perf specifies the sample event period. We suggest using a suitable prime number, like 500009, for this purpose. For Intel platforms: $ perf record -e BR_INST_RETIRED.NEAR_TAKEN:k -a -N -b -c <count> \ -o <perf_file> -- <loadtest> For AMD platforms: The supported system are: Zen3 with BRS, or Zen4 with amd_lbr_v2 # To see if Zen3 support LBR: $ cat proc/cpuinfo | grep " brs" # To see if Zen4 support LBR: $ cat proc/cpuinfo | grep amd_lbr_v2 # If the result is yes, then collect the profile using: $ perf record --pfm-events RETIRED_TAKEN_BRANCH_INSTRUCTIONS:k -a \ -N -b -c <count> -o <perf_file> -- <loadtest> 4) (Optional) Download the raw perf file to the host machine. 5) Generate Propeller profile: $ create_llvm_prof --binary=<vmlinux> --profile=<perf_file> \ --format=propeller --propeller_output_module_name \ --out=<propeller_profile_prefix>_cc_profile.txt \ --propeller_symorder=<propeller_profile_prefix>_ld_profile.txt “create_llvm_prof” is the profile conversion tool, and a prebuilt binary for linux can be found on https://github.com/google/autofdo/releases/tag/v0.30.1 (can also build from source). "<propeller_profile_prefix>" can be something like "/home/user/dir/any_string". This command generates a pair of Propeller profiles: "<propeller_profile_prefix>_cc_profile.txt" and "<propeller_profile_prefix>_ld_profile.txt". 6) Rebuild the kernel using the AutoFDO and Propeller profile files. CONFIG_AUTOFDO_CLANG=y CONFIG_PROPELLER_CLANG=y and $ make LLVM=1 CLANG_AUTOFDO_PROFILE=<autofdo_profile> \ CLANG_PROPELLER_PROFILE_PREFIX=<propeller_profile_prefix> Co-developed-by: Han Shen <shenhan@google.com> Signed-off-by: Han Shen <shenhan@google.com> Signed-off-by: Rong Xu <xur@google.com> Suggested-by: Sriraman Tallam <tmsriram@google.com> Suggested-by: Krzysztof Pszeniczny <kpszeniczny@google.com> Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Suggested-by: Stephane Eranian <eranian@google.com> Tested-by: Yonghong Song <yonghong.song@linux.dev> Tested-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Kees Cook <kees@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-11-26Merge tag 'rust-6.13' of https://github.com/Rust-for-Linux/linuxLinus Torvalds1-4/+12
Pull rust updates from Miguel Ojeda: "Toolchain and infrastructure: - Enable a series of lints, including safety-related ones, e.g. the compiler will now warn about missing safety comments, as well as unnecessary ones. How safety documentation is organized is a frequent source of review comments, thus having the compiler guide new developers on where they are expected (and where not) is very nice. - Start using '#[expect]': an interesting feature in Rust (stabilized in 1.81.0) that makes the compiler warn if an expected warning was _not_ emitted. This is useful to avoid forgetting cleaning up locally ignored diagnostics ('#[allow]'s). - Introduce '.clippy.toml' configuration file for Clippy, the Rust linter, which will allow us to tweak its behaviour. For instance, our first use cases are declaring a disallowed macro and, more importantly, enabling the checking of private items. - Lints-related fixes and cleanups related to the items above. - Migrate from 'receiver_trait' to 'arbitrary_self_types': to get the kernel into stable Rust, one of the major pieces of the puzzle is the support to write custom types that can be used as 'self', i.e. as receivers, since the kernel needs to write types such as 'Arc' that common userspace Rust would not. 'arbitrary_self_types' has been accepted to become stable, and this is one of the steps required to get there. - Remove usage of the 'new_uninit' unstable feature. - Use custom C FFI types. Includes a new 'ffi' crate to contain our custom mapping, instead of using the standard library 'core::ffi' one. The actual remapping will be introduced in a later cycle. - Map '__kernel_{size_t,ssize_t,ptrdiff_t}' to 'usize'/'isize' instead of 32/64-bit integers. - Fix 'size_t' in bindgen generated prototypes of C builtins. - Warn on bindgen < 0.69.5 and libclang >= 19.1 due to a double issue in the projects, which we managed to trigger with the upcoming tracepoint support. It includes a build test since some distributions backported the fix (e.g. Debian -- thanks!). All major distributions we list should be now OK except Ubuntu non-LTS. 'macros' crate: - Adapt the build system to be able run the doctests there too; and clean up and enable the corresponding doctests. 'kernel' crate: - Add 'alloc' module with generic kernel allocator support and remove the dependency on the Rust standard library 'alloc' and the extension traits we used to provide fallible methods with flags. Add the 'Allocator' trait and its implementations '{K,V,KV}malloc'. Add the 'Box' type (a heap allocation for a single value of type 'T' that is also generic over an allocator and considers the kernel's GFP flags) and its shorthand aliases '{K,V,KV}Box'. Add 'ArrayLayout' type. Add 'Vec' (a contiguous growable array type) and its shorthand aliases '{K,V,KV}Vec', including iterator support. For instance, now we may write code such as: let mut v = KVec::new(); v.push(1, GFP_KERNEL)?; assert_eq!(&v, &[1]); Treewide, move as well old users to these new types. - 'sync' module: add global lock support, including the 'GlobalLockBackend' trait; the 'Global{Lock,Guard,LockedBy}' types and the 'global_lock!' macro. Add the 'Lock::try_lock' method. - 'error' module: optimize 'Error' type to use 'NonZeroI32' and make conversion functions public. - 'page' module: add 'page_align' function. - Add 'transmute' module with the existing 'FromBytes' and 'AsBytes' traits. - 'block::mq::request' module: improve rendered documentation. - 'types' module: extend 'Opaque' type documentation and add simple examples for the 'Either' types. drm/panic: - Clean up a series of Clippy warnings. Documentation: - Add coding guidelines for lints and the '#[expect]' feature. - Add Ubuntu to the list of distributions in the Quick Start guide. MAINTAINERS: - Add Danilo Krummrich as maintainer of the new 'alloc' module. And a few other small cleanups and fixes" * tag 'rust-6.13' of https://github.com/Rust-for-Linux/linux: (82 commits) rust: alloc: Fix `ArrayLayout` allocations docs: rust: remove spurious item in `expect` list rust: allow `clippy::needless_lifetimes` rust: warn on bindgen < 0.69.5 and libclang >= 19.1 rust: use custom FFI integer types rust: map `__kernel_size_t` and friends also to usize/isize rust: fix size_t in bindgen prototypes of C builtins rust: sync: add global lock support rust: macros: enable the rest of the tests rust: macros: enable paste! use from macro_rules! rust: enable macros::module! tests rust: kbuild: expand rusttest target for macros rust: types: extend `Opaque` documentation rust: block: fix formatting of `kernel::block::mq::request` module rust: macros: fix documentation of the paste! macro rust: kernel: fix THIS_MODULE header path in ThisModule doc comment rust: page: add Rust version of PAGE_ALIGN rust: helpers: remove unnecessary header includes rust: exports: improve grammar in commentary drm/panic: allow verbose version check ...
2024-11-25rust: allow `clippy::needless_lifetimes`Miguel Ojeda1-0/+1
In beta Clippy (i.e. Rust 1.83.0), the `needless_lifetimes` lint has been extended [1] to suggest eliding `impl` lifetimes, e.g. error: the following explicit lifetimes could be elided: 'a --> rust/kernel/list.rs:647:6 | 647 | impl<'a, T: ?Sized + ListItem<ID>, const ID: u64> FusedIterator for Iter<'a, T, ID> {} | ^^ ^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_lifetimes = note: `-D clippy::needless-lifetimes` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::needless_lifetimes)]` help: elide the lifetimes | 647 - impl<'a, T: ?Sized + ListItem<ID>, const ID: u64> FusedIterator for Iter<'a, T, ID> {} 647 + impl<T: ?Sized + ListItem<ID>, const ID: u64> FusedIterator for Iter<'_, T, ID> {} A possibility would have been to clean them -- the RFC patch [2] did this, while asking if we wanted these cleanups. There is an open issue [3] in Clippy about being able to differentiate some of the new cases, e.g. those that do not involve introducing `'_`. Thus it seems others feel similarly. Thus, for the time being, we decided to `allow` the lint. Link: https://github.com/rust-lang/rust-clippy/pull/13286 [1] Link: https://lore.kernel.org/rust-for-linux/20241012231300.397010-1-ojeda@kernel.org/ [2] Link: https://github.com/rust-lang/rust-clippy/issues/13514 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20241116181538.369355-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-11-17Linux 6.12v6.12Linus Torvalds1-1/+1
2024-11-10Linux 6.12-rc7HEADv6.12-rc7masterLinus Torvalds1-1/+1
2024-11-06kbuild: Add AutoFDO support for Clang buildRong Xu1-0/+1
Add the build support for using Clang's AutoFDO. Building the kernel with AutoFDO does not reduce the optimization level from the compiler. AutoFDO uses hardware sampling to gather information about the frequency of execution of different code paths within a binary. This information is then used to guide the compiler's optimization decisions, resulting in a more efficient binary. Experiments showed that the kernel can improve up to 10% in latency. The support requires a Clang compiler after LLVM 17. This submission is limited to x86 platforms that support PMU features like LBR on Intel machines and AMD Zen3 BRS. Support for SPE on ARM 1, and BRBE on ARM 1 is part of planned future work. Here is an example workflow for AutoFDO kernel: 1) Build the kernel on the host machine with LLVM enabled, for example, $ make menuconfig LLVM=1 Turn on AutoFDO build config: CONFIG_AUTOFDO_CLANG=y With a configuration that has LLVM enabled, use the following command: scripts/config -e AUTOFDO_CLANG After getting the config, build with $ make LLVM=1 2) Install the kernel on the test machine. 3) Run the load tests. The '-c' option in perf specifies the sample event period. We suggest using a suitable prime number, like 500009, for this purpose. For Intel platforms: $ perf record -e BR_INST_RETIRED.NEAR_TAKEN:k -a -N -b -c <count> \ -o <perf_file> -- <loadtest> For AMD platforms: The supported system are: Zen3 with BRS, or Zen4 with amd_lbr_v2 For Zen3: $ cat proc/cpuinfo | grep " brs" For Zen4: $ cat proc/cpuinfo | grep amd_lbr_v2 $ perf record --pfm-events RETIRED_TAKEN_BRANCH_INSTRUCTIONS:k -a \ -N -b -c <count> -o <perf_file> -- <loadtest> 4) (Optional) Download the raw perf file to the host machine. 5) To generate an AutoFDO profile, two offline tools are available: create_llvm_prof and llvm_profgen. The create_llvm_prof tool is part of the AutoFDO project and can be found on GitHub (https://github.com/google/autofdo), version v0.30.1 or later. The llvm_profgen tool is included in the LLVM compiler itself. It's important to note that the version of llvm_profgen doesn't need to match the version of Clang. It needs to be the LLVM 19 release or later, or from the LLVM trunk. $ llvm-profgen --kernel --binary=<vmlinux> --perfdata=<perf_file> \ -o <profile_file> or $ create_llvm_prof --binary=<vmlinux> --profile=<perf_file> \ --format=extbinary --out=<profile_file> Note that multiple AutoFDO profile files can be merged into one via: $ llvm-profdata merge -o <profile_file> <profile_1> ... <profile_n> 6) Rebuild the kernel using the AutoFDO profile file with the same config as step 1, (Note CONFIG_AUTOFDO_CLANG needs to be enabled): $ make LLVM=1 CLANG_AUTOFDO_PROFILE=<profile_file> Co-developed-by: Han Shen <shenhan@google.com> Signed-off-by: Han Shen <shenhan@google.com> Signed-off-by: Rong Xu <xur@google.com> Suggested-by: Sriraman Tallam <tmsriram@google.com> Suggested-by: Krzysztof Pszeniczny <kpszeniczny@google.com> Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Suggested-by: Stephane Eranian <eranian@google.com> Tested-by: Yonghong Song <yonghong.song@linux.dev> Tested-by: Yabin Cui <yabinc@google.com> Tested-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Kees Cook <kees@kernel.org> Tested-by: Peter Jung <ptr1337@cachyos.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-11-06kbuild: simplify rustfmt targetMasahiro Yamada1-11/+2
There is no need to prune the rust/alloc directory because it was removed by commit 9d0441bab775 ("rust: alloc: remove our fork of the `alloc` crate"). There is no need to prune the rust/test directory because no '*.rs' files are generated within it. To avoid forking the 'grep -Fv generated' process, filter out generated files using the option, ! -name '*generated*'. Now that the '-path ... -prune' option is no longer used, there is no need to use the absolute path. Searching in $(srctree), which can be a relative path, is sufficient. The comment mentions the use case where $(srctree) is '..', that is, $(objtree) is a sub-directory of $(srctree). In this scenario, all '*.rs' files under $(objtree) are generated files and filters out by the '*generated*' pattern. Add $(RCS_FIND_IGNORE) as a shortcut. Although I do not believe '*.rs' files would exist under the .git directory, there is no need for the 'find' command to traverse it. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de> Acked-by: Miguel Ojeda <ojeda@kernel.org>
2024-11-05scripts: Remove export_report.plMatthew Maurer1-5/+1
This script has been broken for 5 years with no user complaints. It first had its .mod.c parser broken in commit a3d0cb04f7df ("modpost: use __section in the output to *.mod.c"). Later, it had its object file enumeration broken in commit f65a486821cf ("kbuild: change module.order to list *.o instead of *.ko"). Both of these changes sat for years with no reports. Rather than reviving this script as we make further changes to `.mod.c`, this patch gets rid of it because it is clearly unused. Signed-off-by: Matthew Maurer <mmaurer@google.com> Acked-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
2024-11-04kbuild: add generic support for built-in boot DTBsMasahiro Yamada1-1/+6
Some architectures embed boot DTBs in vmlinux. A potential issue for these architectures is a race condition during parallel builds because Kbuild descends into arch/*/boot/dts/ twice. One build thread is initiated by the 'dtbs' target, which is a prerequisite of the 'all' target in the top-level Makefile: ifdef CONFIG_OF_EARLY_FLATTREE all: dtbs endif For architectures that support the built-in boot dtb, arch/*/boot/dts/ is visited also during the ordinary directory traversal in order to build obj-y objects that wrap DTBs. Since these build threads are unaware of each other, they can run simultaneously during parallel builds. This commit introduces a generic build rule to scripts/Makefile.vmlinux to support embedded boot DTBs in a race-free way. Architectures that want to use this rule need to select CONFIG_GENERIC_BUILTIN_DTB. After the migration, Makefiles under arch/*/boot/dts/ will be visited only once to build only *.dtb files. This change also aims to unify the CONFIG options used for built-in DTBs support. Currently, different architectures use different CONFIG options for the same purposes. With this commit, the CONFIG options will be unified as follows: - CONFIG_GENERIC_BUILTIN_DTB This enables the generic rule for built-in boot DTBs. This will be renamed to CONFIG_BUILTIN_DTB after all architectures migrate to the generic rule. - CONFIG_BUILTIN_DTB_NAME This specifies the path to the embedded DTB. (relative to arch/*/boot/dts/) - CONFIG_BUILTIN_DTB_ALL If this is enabled, all DTB files compiled under arch/*/boot/dts/ are embedded into vmlinux. Only used by MIPS. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-11-04kbuild: check the presence of include/generated/rustc_cfgMasahiro Yamada1-2/+3
Since commit 2f7ab1267dc9 ("Kbuild: add Rust support"), Kconfig generates include/generated/rustc_cfg, but its presence is not checked in the top-level Makefile. It should be checked similarly to the C header counterpart, include/generated/autoconf.h. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de> Acked-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Miguel Ojeda <ojeda@kernel.org>
2024-11-04kbuild: refactor the check for missing config filesMasahiro Yamada1-8/+13
This commit refactors the check for missing configuration files, making it easier to add more files to the list. The format of the error message has been slightly changed, as follows: [Before] ERROR: Kernel configuration is invalid. include/generated/autoconf.h or include/config/auto.conf are missing. Run 'make oldconfig && make prepare' on kernel src to fix it. [After] *** *** ERROR: Kernel configuration is invalid. The following files are missing: *** - include/generated/autoconf.h *** - include/config/auto.conf *** Run "make oldconfig && make prepare" on kernel source to fix it. *** Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de> Tested-by: Miguel Ojeda <ojeda@kernel.org>
2024-11-03Linux 6.12-rc6v6.12-rc6Linus Torvalds1-1/+1
2024-10-27Linux 6.12-rc5v6.12-rc5Linus Torvalds1-1/+1
2024-10-20Linux 6.12-rc4v6.12-rc4Linus Torvalds1-1/+1
2024-10-13Linux 6.12-rc3v6.12-rc3Linus Torvalds1-1/+1
generated by cgit v1.2.3 (git 2.25.1) at 2026-02-25 14:56:34 +0000