diff options
79 files changed, 2873 insertions, 1777 deletions
diff --git a/.gitattributes b/.gitattributes index 4b32eaa9571e..c9ba5bfc4036 100644 --- a/.gitattributes +++ b/.gitattributes @@ -1,4 +1,4 @@ -*.c diff=cpp -*.h diff=cpp -*.dtsi diff=dts -*.dts diff=dts +# SPDX-License-Identifier: GPL-2.0-only +*.[ch] diff=cpp +*.dts diff=dts +*.dts[io] diff=dts diff --git a/.gitignore b/.gitignore index 20dce5c3b9e0..8fe465f251c0 100644 --- a/.gitignore +++ b/.gitignore @@ -4,7 +4,7 @@ # subdirectories here. Add them in the ".gitignore" file # in that subdirectory instead. # -# NOTE! Please use 'git ls-files -i --exclude-standard' +# NOTE! Please use 'git ls-files -i -c --exclude-per-directory=.gitignore' # command after changing this file, to see if there are # any tracked files which get ignored after the change. # @@ -16,6 +16,7 @@ *.bin *.bz2 *.c.[012]*.* +*.cover *.dt.yaml *.dtb *.dtbo @@ -33,6 +34,7 @@ *.lz4 *.lzma *.lzo +*.mbx *.mod *.mod.c *.o diff --git a/Documentation/Makefile b/Documentation/Makefile index bb73dcb5ed05..023fa658a0a8 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -28,7 +28,7 @@ BUILDDIR = $(obj)/output PDFLATEX = xelatex LATEXOPTS = -interaction=batchmode -no-shell-escape -ifeq ($(KBUILD_VERBOSE),0) +ifeq ($(findstring 1, $(KBUILD_VERBOSE)),) SPHINXOPTS += "-q" endif diff --git a/Documentation/dontdiff b/Documentation/dontdiff index 352ff53a2306..3c399f132e2d 100644 --- a/Documentation/dontdiff +++ b/Documentation/dontdiff @@ -91,7 +91,6 @@ asm_offsets.h autoconf.h* av_permissions.h bbootsect -bin2c binkernel.spec bootsect bounds.h diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst index 6b2bac8e9ce0..bfb51685073c 100644 --- a/Documentation/kbuild/llvm.rst +++ b/Documentation/kbuild/llvm.rst @@ -15,12 +15,15 @@ such as GCC and binutils. Ongoing work has allowed for `Clang <https://clang.llvm.org/>`_ and `LLVM <https://llvm.org/>`_ utilities to be used as viable substitutes. Distributions such as `Android <https://www.android.com/>`_, `ChromeOS -<https://www.chromium.org/chromium-os>`_, and `OpenMandriva -<https://www.openmandriva.org/>`_ use Clang built kernels. `LLVM is a -collection of toolchain components implemented in terms of C++ objects -<https://www.aosabook.org/en/llvm.html>`_. Clang is a front-end to LLVM that -supports C and the GNU C extensions required by the kernel, and is pronounced -"klang," not "see-lang." +<https://www.chromium.org/chromium-os>`_, `OpenMandriva +<https://www.openmandriva.org/>`_, and `Chimera Linux +<https://chimera-linux.org/>`_ use Clang built kernels. Google's and Meta's +datacenter fleets also run kernels built with Clang. + +`LLVM is a collection of toolchain components implemented in terms of C++ +objects <https://www.aosabook.org/en/llvm.html>`_. Clang is a front-end to LLVM +that supports C and the GNU C extensions required by the kernel, and is +pronounced "klang," not "see-lang." Clang ----- diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst index 38bc74eaa547..e67eb261c9b0 100644 --- a/Documentation/kbuild/makefiles.rst +++ b/Documentation/kbuild/makefiles.rst @@ -4,69 +4,8 @@ Linux Kernel Makefiles This document describes the Linux kernel Makefiles. -.. Table of Contents - - === 1 Overview - === 2 Who does what - === 3 The kbuild files - --- 3.1 Goal definitions - --- 3.2 Built-in object goals - obj-y - --- 3.3 Loadable module goals - obj-m - --- 3.4 <deleted> - --- 3.5 Library file goals - lib-y - --- 3.6 Descending down in directories - --- 3.7 Non-builtin vmlinux targets - extra-y - --- 3.8 Always built goals - always-y - --- 3.9 Compilation flags - --- 3.10 Dependency tracking - --- 3.11 Custom Rules - --- 3.12 Command change detection - --- 3.13 $(CC) support functions - --- 3.14 $(LD) support functions - --- 3.15 Script Invocation - - === 4 Host Program support - --- 4.1 Simple Host Program - --- 4.2 Composite Host Programs - --- 4.3 Using C++ for host programs - --- 4.4 Using Rust for host programs - --- 4.5 Controlling compiler options for host programs - --- 4.6 When host programs are actually built - - === 5 Userspace Program support - --- 5.1 Simple Userspace Program - --- 5.2 Composite Userspace Programs - --- 5.3 Controlling compiler options for userspace programs - --- 5.4 When userspace programs are actually built - - === 6 Kbuild clean infrastructure - - === 7 Architecture Makefiles - --- 7.1 Set variables to tweak the build to the architecture - --- 7.2 Add prerequisites to archheaders - --- 7.3 Add prerequisites to archprepare - --- 7.4 List directories to visit when descending - --- 7.5 Architecture-specific boot images - --- 7.6 Building non-kbuild targets - --- 7.7 Commands useful for building a boot image - --- 7.8 <deleted> - --- 7.9 Preprocessing linker scripts - --- 7.10 Generic header files - --- 7.11 Post-link pass - - === 8 Kbuild syntax for exported headers - --- 8.1 no-export-headers - --- 8.2 generic-y - --- 8.3 generated-y - --- 8.4 mandatory-y - - === 9 Kbuild Variables - === 10 Makefile language - === 11 Credits - === 12 TODO - -1 Overview -========== +Overview +======== The Makefiles have five parts:: @@ -83,6 +22,7 @@ The top Makefile is responsible for building two major products: vmlinux (the resident kernel image) and modules (any module files). It builds these goals by recursively descending into the subdirectories of the kernel source tree. + The list of subdirectories which are visited depends upon the kernel configuration. The top Makefile textually includes an arch Makefile with the name arch/$(SRCARCH)/Makefile. The arch Makefile supplies @@ -96,14 +36,13 @@ any built-in or modular targets. scripts/Makefile.* contains all the definitions/rules etc. that are used to build the kernel based on the kbuild makefiles. - -2 Who does what -=============== +Who does what +============= People have four different relationships with the kernel Makefiles. *Users* are people who build kernels. These people type commands such as -"make menuconfig" or "make". They usually do not read or edit +``make menuconfig`` or ``make``. They usually do not read or edit any kernel Makefiles (or any other source files). *Normal developers* are people who work on features such as device @@ -123,1402 +62,1429 @@ These people need to know about all aspects of the kernel Makefiles. This document is aimed towards normal developers and arch developers. -3 The kbuild files -================== +The kbuild files +================ Most Makefiles within the kernel are kbuild Makefiles that use the kbuild infrastructure. This chapter introduces the syntax used in the kbuild makefiles. -The preferred name for the kbuild files are 'Makefile' but 'Kbuild' can -be used and if both a 'Makefile' and a 'Kbuild' file exists, then the 'Kbuild' + +The preferred name for the kbuild files are ``Makefile`` but ``Kbuild`` can +be used and if both a ``Makefile`` and a ``Kbuild`` file exists, then the ``Kbuild`` file will be used. -Section 3.1 "Goal definitions" is a quick intro; further chapters provide +Section `Goal definitions`_ is a quick intro; further chapters provide more details, with real examples. -3.1 Goal definitions --------------------- +Goal definitions +---------------- - Goal definitions are the main part (heart) of the kbuild Makefile. - These lines define the files to be built, any special compilation - options, and any subdirectories to be entered recursively. +Goal definitions are the main part (heart) of the kbuild Makefile. +These lines define the files to be built, any special compilation +options, and any subdirectories to be entered recursively. - The most simple kbuild makefile contains one line: +The most simple kbuild makefile contains one line: - Example:: +Example:: - obj-y += foo.o + obj-y += foo.o - This tells kbuild that there is one object in that directory, named - foo.o. foo.o will be built from foo.c or foo.S. +This tells kbuild that there is one object in that directory, named +foo.o. foo.o will be built from foo.c or foo.S. - If foo.o shall be built as a module, the variable obj-m is used. - Therefore the following pattern is often used: +If foo.o shall be built as a module, the variable obj-m is used. +Therefore the following pattern is often used: - Example:: +Example:: - obj-$(CONFIG_FOO) += foo.o + obj-$(CONFIG_FOO) += foo.o - $(CONFIG_FOO) evaluates to either y (for built-in) or m (for module). - If CONFIG_FOO is neither y nor m, then the file will not be compiled - nor linked. +$(CONFIG_FOO) evaluates to either y (for built-in) or m (for module). +If CONFIG_FOO is neither y nor m, then the file will not be compiled +nor linked. -3.2 Built-in object goals - obj-y ---------------------------------- +Built-in object goals - obj-y +----------------------------- - The kbuild Makefile specifies object files for vmlinux - in the $(obj-y) lists. These lists depend on the kernel - configuration. +The kbuild Makefile specifies object files for vmlinux +in the $(obj-y) lists. These lists depend on the kernel +configuration. - Kbuild compiles all the $(obj-y) files. It then calls - "$(AR) rcSTP" to merge these files into one built-in.a file. - This is a thin archive without a symbol table. It will be later - linked into vmlinux by scripts/link-vmlinux.sh +Kbuild compiles all the $(obj-y) files. It then calls +``$(AR) rcSTP`` to merge these files into one built-in.a file. +This is a thin archive without a symbol table. It will be later +linked into vmlinux by scripts/link-vmlinux.sh - The order of files in $(obj-y) is significant. Duplicates in - the lists are allowed: the first instance will be linked into - built-in.a and succeeding instances will be ignored. +The order of files in $(obj-y) is significant. Duplicates in +the lists are allowed: the first instance will be linked into +built-in.a and succeeding instances will be ignored. - Link order is significant, because certain functions - (module_init() / __initcall) will be called during boot in the - order they appear. So keep in mind that changing the link - order may e.g. change the order in which your SCSI - controllers are detected, and thus your disks are renumbered. +Link order is significant, because certain functions +(module_init() / __initcall) will be called during boot in the +order they appear. So keep in mind that changing the link +order may e.g. change the order in which your SCSI +controllers are detected, and thus your disks are renumbered. - Example:: +Example:: - #drivers/isdn/i4l/Makefile - # Makefile for the kernel ISDN subsystem and device drivers. - # Each configuration option enables a list of files. - obj-$(CONFIG_ISDN_I4L) += isdn.o - obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o + #drivers/isdn/i4l/Makefile + # Makefile for the kernel ISDN subsystem and device drivers. + # Each configuration option enables a list of files. + obj-$(CONFIG_ISDN_I4L) += isdn.o + obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o -3.3 Loadable module goals - obj-m ---------------------------------- +Loadable module goals - obj-m +----------------------------- - $(obj-m) specifies object files which are built as loadable - kernel modules. +$(obj-m) specifies object files which are built as loadable +kernel modules. - A module may be built from one source file or several source - files. In the case of one source file, the kbuild makefile - simply adds the file to $(obj-m). +A module may be built from one source file or several source +files. In the case of one source file, the kbuild makefile +simply adds the file to $(obj-m). - Example:: +Example:: - #drivers/isdn/i4l/Makefile - obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o + #drivers/isdn/i4l/Makefile + obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o - Note: In this example $(CONFIG_ISDN_PPP_BSDCOMP) evaluates to 'm' +Note: In this example $(CONFIG_ISDN_PPP_BSDCOMP) evaluates to "m" - If a kernel module is built from several source files, you specify - that you want to build a module in the same way as above; however, - kbuild needs to know which object files you want to build your - module from, so you have to tell it by setting a $(<module_name>-y) - variable. +If a kernel module is built from several source files, you specify +that you want to build a module in the same way as above; however, +kbuild needs to know which object files you want to build your +module from, so you have to tell it by setting a $(<module_name>-y) +variable. - Example:: +Example:: - #drivers/isdn/i4l/Makefile - obj-$(CONFIG_ISDN_I4L) += isdn.o - isdn-y := isdn_net_lib.o isdn_v110.o isdn_common.o + #drivers/isdn/i4l/Makefile + obj-$(CONFIG_ISDN_I4L) += isdn.o + isdn-y := isdn_net_lib.o isdn_v110.o isdn_common.o - In this example, the module name will be isdn.o. Kbuild will - compile the objects listed in $(isdn-y) and then run - "$(LD) -r" on the list of these files to generate isdn.o. +In this example, the module name will be isdn.o. Kbuild will +compile the objects listed in $(isdn-y) and then run +``$(LD) -r`` on the list of these files to generate isdn.o. - Due to kbuild recognizing $(<module_name>-y) for composite objects, - you can use the value of a `CONFIG_` symbol to optionally include an - object file as part of a composite object. +Due to kbuild recognizing $(<module_name>-y) for composite objects, +you can use the value of a ``CONFIG_`` symbol to optionally include an +object file as part of a composite object. - Example:: +Example:: - #fs/ext2/Makefile - obj-$(CONFIG_EXT2_FS) += ext2.o - ext2-y := balloc.o dir.o file.o ialloc.o inode.o ioctl.o \ - namei.o super.o symlink.o - ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o xattr_user.o \ - xattr_trusted.o + #fs/ext2/Makefile + obj-$(CONFIG_EXT2_FS) += ext2.o + ext2-y := balloc.o dir.o file.o ialloc.o inode.o ioctl.o \ + namei.o super.o symlink.o + ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o xattr_user.o \ + xattr_trusted.o - In this example, xattr.o, xattr_user.o and xattr_trusted.o are only - part of the composite object ext2.o if $(CONFIG_EXT2_FS_XATTR) - evaluates to 'y'. +In this example, xattr.o, xattr_user.o and xattr_trusted.o are only +part of the composite object ext2.o if $(CONFIG_EXT2_FS_XATTR) +evaluates to "y". - Note: Of course, when you are building objects into the kernel, - the syntax above will also work. So, if you have CONFIG_EXT2_FS=y, - kbuild will build an ext2.o file for you out of the individual - parts and then link this into built-in.a, as you would expect. +Note: Of course, when you are building objects into the kernel, +the syntax above will also work. So, if you have CONFIG_EXT2_FS=y, +kbuild will build an ext2.o file for you out of the individual +parts and then link this into built-in.a, as you would expect. -3.5 Library file goals - lib-y ------------------------------- +Library file goals - lib-y +-------------------------- - Objects listed with obj-* are used for modules, or - combined in a built-in.a for that specific directory. - There is also the possibility to list objects that will - be included in a library, lib.a. - All objects listed with lib-y are combined in a single - library for that directory. - Objects that are listed in obj-y and additionally listed in - lib-y will not be included in the library, since they will - be accessible anyway. - For consistency, objects listed in lib-m will be included in lib.a. +Objects listed with obj-* are used for modules, or +combined in a built-in.a for that specific directory. +There is also the possibility to list objects that will +be included in a library, lib.a. +All objects listed with lib-y are combined in a single +library for that directory. +Objects that are listed in obj-y and additionally listed in +lib-y will not be included in the library, since they will +be accessible anyway. +For consistency, objects listed in lib-m will be included in lib.a. - Note that the same kbuild makefile may list files to be built-in - and to be part of a library. Therefore the same directory - may contain both a built-in.a and a lib.a file. +Note that the same kbuild makefile may list files to be built-in +and to be part of a library. Therefore the same directory +may contain both a built-in.a and a lib.a file. - Example:: +Example:: - #arch/x86/lib/Makefile - lib-y := delay.o + #arch/x86/lib/Makefile + lib-y := delay.o - This will create a library lib.a based on delay.o. For kbuild to - actually recognize that there is a lib.a being built, the directory - shall be listed in libs-y. +This will create a library lib.a based on delay.o. For kbuild to +actually recognize that there is a lib.a being built, the directory +shall be listed in libs-y. - See also "7.4 List directories to visit when descending". +See also |