summaryrefslogtreecommitdiff
path: root/scripts/Makefile.modinst
AgeCommit message (Collapse)AuthorFilesLines
2024-11-28kbuild: remove extmod_prefix, MODORDER, MODULES_NSDEPS variablesMasahiro Yamada1-3/+3
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-27kbuild: add $(objtree)/ prefix to some in-kernel build artifactsMasahiro Yamada1-1/+1
$(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-09-28Merge tag 'modules-6.12-rc1' of ↵Linus Torvalds1-0/+2
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux Pull module updates from Luis Chamberlain: "There are a few fixes / cleanups from Vincent, Chunhui, and Petr, but the most important part of this pull request is the Rust community stepping up to help maintain both C / Rust code for future Rust module support. We grow the set of modules maintainers by three now, and with this hope to scale to help address what's needed to properly support future Rust module support. A lot of exciting stuff coming in future kernel releases. This has been on linux-next for ~ 3 weeks now with no issues" * tag 'modules-6.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux: module: Refine kmemleak scanned areas module: abort module loading when sysfs setup suffer errors MAINTAINERS: scale modules with more reviewers module: Clean up the description of MODULE_SIG_<type> module: Split modules_install compression and in-kernel decompression
2024-09-20kbuild: add install target for modules.builtin.rangesKris Van Hees1-2/+4
When CONFIG_BUILTIN_MODULE_RANGES is enabled, the modules.builtin.ranges file should be installed in the module install location. Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com> Reviewed-by: Nick Alcock <nick.alcock@oracle.com> Tested-by: Sam James <sam@gentoo.org> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Tested-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-09-01kbuild: modinst: remove the multithread option from zstd compressionMasahiro Yamada1-1/+1
Parallel execution is supported by GNU Make: $ make -j<N> modules_install It is questionable to enable multithreading within each zstd process by default. If you still want to do it, you can use the environment variable: $ ZSTD_NBTHREADS=<N> make modules_install Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
2024-08-19module: Split modules_install compression and in-kernel decompressionPetr Pavlu1-0/+2
The kernel configuration allows specifying a module compression mode. If one is selected then each module gets compressed during 'make modules_install' and additionally one can also enable support for a respective direct in-kernel decompression support. This means that the decompression support cannot be enabled without the automatic compression. Some distributions, such as the (open)SUSE family, use a signer service for modules. A build runs on a worker machine but signing is done by a separate locked-down server that is in possession of the signing key. The build invokes 'make modules_install' to create a modules tree, collects information about the modules, asks the signer service for their signature, appends each signature to the respective module and compresses all modules. When using this arrangment, the 'make modules_install' step produces unsigned+uncompressed modules and the distribution's own build recipe takes care of signing and compression later. The signing support can be currently enabled without automatically signing modules during 'make modules_install'. However, the in-kernel decompression support can be selected only after first enabling automatic compression during this step. To allow only enabling the in-kernel decompression support without the automatic compression during 'make modules_install', separate the compression options similarly to the signing options, as follows: > Enable loadable module support [*] Module compression Module compression type (GZIP) ---> [*] Automatically compress all modules [ ] Support in-kernel module decompression * "Module compression" (MODULE_COMPRESS) is a new main switch for the compression/decompression support. It replaces MODULE_COMPRESS_NONE. * "Module compression type" (MODULE_COMPRESS_<type>) chooses the compression type, one of GZ, XZ, ZSTD. * "Automatically compress all modules" (MODULE_COMPRESS_ALL) is a new option to enable module compression during 'make modules_install'. It defaults to Y. * "Support in-kernel module decompression" (MODULE_DECOMPRESS) enables in-kernel decompression. Signed-off-by: Petr Pavlu <petr.pavlu@suse.com> Acked-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
2023-09-25kbuild: Use CRC32 and a 1MiB dictionary for XZ compressed modulesMartin Nybo Andersen1-1/+1
Kmod is now (since kmod commit 09c9f8c5df04 ("libkmod: Use kernel decompression when available")) using the kernel decompressor, when loading compressed modules. However, the kernel XZ decompressor is XZ Embedded, which doesn't handle CRC64 and dictionaries larger than 1MiB. Use CRC32 and 1MiB dictionary when XZ compressing and installing kernel modules. Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050582 Signed-off-by: Martin Nybo Andersen <tweek@tweek.dk> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2023-09-15kbuild: avoid long argument lists in make modules_installMichal Kubecek1-1/+1
Running "make modules_install" may fail with make[2]: execvp: /bin/sh: Argument list too long if many modules are built and INSTALL_MOD_PATH is long. This is because scripts/Makefile.modinst creates all directories with one mkdir command. Use $(foreach ...) instead to prevent an excessive argument list. Fixes: 2dfec887c0fd ("kbuild: reduce the number of mkdir calls during modules_install") Signed-off-by: Michal Kubecek <mkubecek@suse.cz> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2023-09-01kbuild: support modules_sign for external modules as wellMasahiro Yamada1-2/+2
The modules_sign target is currently only available for in-tree modules, but it actually works for external modules as well. Move the modules_sign rule to the common part. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2023-09-01kbuild: support 'make modules_sign' with CONFIG_MODULE_SIG_ALL=nMasahiro Yamada1-4/+5
Commit d890f510c8e4 ("MODSIGN: Add modules_sign make target") introduced 'make modules_sign' to manually sign modules. Some time later, commit d9d8d7ed498e ("MODSIGN: Add option to not sign modules during modules_install") introduced CONFIG_MODULE_SIG_ALL. If it was disabled, mod_sign_cmd was set to no-op ('true' command). It affected not only 'make modules_install' but also 'make modules_sign'. With CONFIG_MODULE_SIG_ALL=n, neither modules_install nor modules_sign is able to sign modules. Kbuild has kept that behavior, and nobody has complained about it, but I think it is weird. CONFIG_MODULE_SIG_ALL=n should turn off signing only for modules_install. If users want to sign modules manually, modules_sign should be offered. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2023-09-01kbuild: move more module installation code to scripts/Makefile.modinstMasahiro Yamada1-2/+31
Move more relevant code to scripts/Makefile.modinst. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2023-09-01kbuild: reduce the number of mkdir calls during modules_installMasahiro Yamada1-1/+7
Calling 'mkdir' for every module results in redundant syscalls. Use $(sort ...) to drop the duplicated directories. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2023-08-29kbuild: move depmod rule to scripts/Makefile.modinstMasahiro Yamada1-0/+9
depmod is a part of the module installation. scripts/Makefile.modinst is a better place to run it. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2023-02-23Merge tag 'modules-6.3-rc1' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux Pull modules updates from Luis Chamberlain: "Nothing exciting at all for modules for v6.3. The biggest change is just the change of INSTALL_MOD_DIR from "extra" to "updates" which I found lingered for ages for no good reason while testing the CXL mock driver [0]. The CXL mock driver has no kconfig integration and requires building an external module... and re-building the *rest* of the production drivers. This mock driver when loaded but not the production ones will crash. All this can obviously be fixed by integrating kconfig semantics into such test module, however that's not desirable by the maintainer, and so sensible defaults must be used to ensure a default "make modules_install" will suffice for most distros which do not have a file like /etc/depmod.d/dist.conf with something like `search updates extra built-in`. Since most distros rely on kmod and since its inception the "updates" directory is always in the search path it makes more sense to use that than the "extra" which only *some* RH based systems rely on. All this stuff has been on linux-next for a while" [0] https://lkml.kernel.org/r/20221209062919.1096779-1-mcgrof@kernel.org * tag 'modules-6.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux: Documentation: livepatch: module-elf-format: Remove local klp_modinfo definition module.h: Document klp_modinfo struct using kdoc module: Use kstrtobool() instead of strtobool() kernel/params.c: Use kstrtobool() instead of strtobool() test_kmod: stop kernel-doc warnings kbuild: Modify default INSTALL_MOD_DIR from extra to updates
2023-01-31kbuild: modinst: Fix build error when CONFIG_MODULE_SIG_KEY is a PKCS#11 URIJan Luebbe1-1/+5
When CONFIG_MODULE_SIG_KEY is PKCS#11 URI (pkcs11:*), signing of modules fails: scripts/sign-file sha256 /.../linux/pkcs11:token=foo;object=bar;pin-value=1111 certs/signing_key.x509 /.../kernel/crypto/tcrypt.ko Usage: scripts/sign-file [-dp] <hash algo> <key> <x509> <module> [<dest>] scripts/sign-file -s <raw sig> <hash algo> <x509> <module> [<dest>] First, we need to avoid adding the $(srctree)/ prefix to the URL. Second, since the kconfig string values no longer include quotes, we need to add them again when passing a PKCS#11 URI to sign-file. This avoids splitting by the shell if the URI contains semicolons. Fixes: 4db9c2e3d055 ("kbuild: stop using config_filename in scripts/Makefile.modsign") Fixes: 129ab0d2d9f3 ("kbuild: do not quote string values in include/config/auto.conf") Signed-off-by: Jan Luebbe <jlu@pengutronix.de> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2023-01-25kbuild: Modify default INSTALL_MOD_DIR from extra to updatesLuis Chamberlain1-1/+1
The default INSTALL_MOD_DIR of using the /lib/modules/$(uname -r)/extra directory for external modules assumes distributions will have something like /etc/depmod.d/dist.conf with: search updates extra built-in However, only some Red Hat releases have and use the "extra" stuff for years now. Meanwhile, the depmod.c tool in kmod has *forever* used the "updates" directory as part of the search path by default *if* your distribution does not have any depmod.d configuration. If you compile and install an external module today, even upstream kernel mock drivers (tools/testing/cxl) the modules_install target will pick up the new drivers but will not allow override of drivers from updates to override built-in ones. Since module-init-tools was deprecated over 11 years ago and now kmod has since its inception used the "updates" directory as part of its default search path to allow overrides, and since the "extra" stuff was in practice only used by Red Hat stuff, use the more distro agnostic override path "updates" to allow external modules to also override proper production kernel modules. This would allow mocking drivers tools to not have to muck with depmod.d config files or assume that your distro will have extra on a configuration file over built-in. With today's default you end up actually *crashing* Linux when trying to load cxl_test with the default "extra" [0] directory being used. This fixes that and allows other mocking drivers to do less work. [0] https://lkml.kernel.org/r/20221209062919.1096779-1-mcgrof@kernel.org Signed-off-by: Luis Chamberlain <mcgrof@kernel.org> Acked-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2022-12-14kbuild: change module.order to list *.o instead of *.koMasahiro Yamada1-1/+1
scripts/Makefile.build replaces the suffix .o with .ko, then scripts/Makefile.modpost calls the sed command to change .ko back to the original .o suffix. Instead of converting the suffixes back-and-forth, store the .o paths in modules.order, and replace it with .ko in 'make modules_install'. This avoids the unneeded sed command. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
2022-12-13kbuild: add read-file macroMasahiro Yamada1-1/+1
Since GNU Make 4.2, $(file ...) supports the read operater '<', which is useful to read a file without forking a new process. No warning is shown even if the input file is missing. For older Make versions, it falls back to the cat command. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> Reviewed-by: Alexander Lobakin <alexandr.lobakin@intel.com> Tested-by: Alexander Lobakin <alexandr.lobakin@intel.com>
2022-12-13kbuild: do not sort after reading modules.orderMasahiro Yamada1-1/+1
modules.order lists modules in the deterministic order (that is why "modules order"), and there is no duplication in the list. $(sort ) is pointless. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2022-07-27kbuild: error out if $(INSTALL_MOD_PATH) contains % or :Masahiro Yamada1-0/+3
If the directory path given to INSTALL_MOD_PATH contains % or :, the module_install fails. % is used in pattern rules, and : as the separator of dependencies. Bail out with a clearer error message. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de>
2022-07-10kbuild: remove unused cmd_none in scripts/Makefile.modinstMasahiro Yamada1-3/+0
Commit 65ce9c38326e ("kbuild: move module strip/compression code into scripts/Makefile.modinst") added this unused code. Perhaps, I thought cmd_none was useful for CONFIG_MODULE_COMPRESS_NONE, but I did not use it after all. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2022-01-08kbuild: do not quote string values in include/config/auto.confMasahiro Yamada1-1/+0
The previous commit fixed up all shell scripts to not include include/config/auto.conf. Now that include/config/auto.conf is only included by Makefiles, we can change it into a more Make-friendly form. Previously, Kconfig output string values enclosed with double-quotes (both in the .config and include/config/auto.conf): CONFIG_X="foo bar" Unlike shell, Make handles double-quotes (and single-quotes as well) verbatim. We must rip them off when used. There are some patterns: [1] $(patsubst "%",%,$(CONFIG_X)) [2] $(CONFIG_X:"%"=%) [3] $(subst ",,$(CONFIG_X)) [4] $(shell echo $(CONFIG_X)) These are not only ugly, but also fragile. [1] and [2] do not work if the value contains spaces, like CONFIG_X=" foo bar " [3] does not work correctly if the value contains double-quotes like CONFIG_X="foo\"bar" [4] seems to work better, but has a cost of forking a process. Anyway, quoted strings were always PITA for our Makefiles. This commit changes Kconfig to stop quoting in include/config/auto.conf. These are the string type symbols referenced in Makefiles or scripts: ACPI_CUSTOM_DSDT_FILE ARC_BUILTIN_DTB_NAME ARC_TUNE_MCPU BUILTIN_DTB_SOURCE CC_IMPLICIT_FALLTHROUGH CC_VERSION_TEXT CFG80211_EXTRA_REGDB_KEYDIR EXTRA_FIRMWARE EXTRA_FIRMWARE_DIR EXTRA_TARGETS H8300_BUILTIN_DTB INITRAMFS_SOURCE LOCALVERSION MODULE_SIG_HASH MODULE_SIG_KEY NDS32_BUILTIN_DTB NIOS2_DTB_SOURCE OPENRISC_BUILTIN_DTB SOC_CANAAN_K210_DTB_SOURCE SYSTEM_BLACKLIST_HASH_LIST SYSTEM_REVOCATION_KEYS SYSTEM_TRUSTED_KEYS TARGET_CPU UNUSED_KSYMS_WHITELIST XILINX_MICROBLAZE0_FAMILY XILINX_MICROBLAZE0_HW_VER XTENSA_VARIANT_NAME I checked them one by one, and fixed up the code where necessary. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-01-08kbuild: stop using config_filename in scripts/Makefile.modsignMasahiro Yamada1-2/+3
Toward the goal of removing the config_filename macro, drop the double-quotes and add $(srctree)/ prefix in an ad hoc way. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de>
2021-04-25kbuild: add support for zstd compressed modulesPiotr Gorski1-0/+6
kmod 28 supports modules compressed in zstd format so let's add this possibility to kernel. Signed-off-by: Piotr Gorski <lucjan.lucjanov@gmail.com> Reviewed-by: Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-04-25kbuild: merge scripts/Makefile.modsign to scripts/Makefile.modinstMasahiro Yamada1-0/+9
scripts/Makefile.modsign is a subset of scripts/Makefile.modinst, and duplicates the code. Let's merge them. By the way, you do not need to run 'make modules_sign' explicitly because modules are signed as a part of 'make modules_install' when CONFIG_MODULE_SIG_ALL=y. If CONFIG_MODULE_SIG_ALL=n, mod_sign_cmd is set to 'true', so 'make modules_sign' is not functional. In my understanding, the reason of still keeping this is to handle corner cases like commit 64178cb62c32 ("builddeb: fix stripped module signatures if CONFIG_DEBUG_INFO and CONFIG_MODULE_SIG_ALL are set"). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-04-25kbuild: move module strip/compression code into scripts/Makefile.modinstMasahiro Yamada1-8/+68
Both mod_strip_cmd and mod_compress_cmd are only used in scripts/Makefile.modinst, hence there is no good reason to define them in the top Makefile. Move the relevant code to scripts/Makefile.modinst. Also, show separate log messages for each of install, strip, sign, and compress. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-04-25kbuild: refactor scripts/Makefile.modinstMasahiro Yamada1-18/+22
scripts/Makefile.modinst is ugly and weird in multiple ways; it specifies real files $(modules) as phony, makes directory manipulation needlessly too complicated. Clean up the Makefile code, and show the full path of installed modules in the log. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-03-15kbuild: prefix $(srctree)/ to some included MakefilesMasahiro Yamada1-1/+1
VPATH is used in Kbuild to make pattern rules search for prerequisites in both $(objtree) and $(srctree). Some of *.c, *.S files are not real sources, but generated by tools such as flex, bison, perl. In contrast, I doubt the benefit of --include-dir=$(abs_srctree) because it is always clear which Makefiles are real sources, and which are not. So, my hope is to add $(srctree)/ prefix to all check-in Makefiles, then remove --include-dir=$(abs_srctree) flag in the future. I am touching only some Kbuild core parts for now. Treewide fixes will be needed to achieve this goal. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2019-07-17kbuild: modinst: read modules.order instead of $(MODVERDIR)/*.modMasahiro Yamada1-4/+1
Towards the goal of removing MODVERDIR, read out modules.order to get the list of modules to be installed. This is simpler than parsing *.mod files in $(MODVERDIR). For external modules, $(KBUILD_EXTMOD)/modules.order should be read. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-03-17Revert "modsign: Abort modules_install when signing fails"Douglas Anderson1-1/+1
This reverts commit caf6fe91ddf62a96401e21e9b7a07227440f4185. The commit was fine but is no longer needed as of commit 3a2429e1faf4 ("kbuild: change if_changed_rule for multi-line recipe"). Let's go back to using ";" to be consistent. For some discussion, see: https://lkml.kernel.org/r/CAK7LNASde0Q9S5GKeQiWhArfER4S4wL1=R_FW8q0++_X3T5=hQ@mail.gmail.com Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-06kbuild: remove duplicated comments about PHONYMasahiro Yamada1-4/+0
The comment is the same as in the top-level Makefile. Also, the comments contain typos: - the .PHONY variable -> the PHONY variable - se we can ... -> so we can ... Instead of fixing the typos, just remove the duplicated comments. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman1-0/+1
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-08-07modsign: Abort modules_install when signing failsDavid Woodhouse1-1/+1
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: David Howells <dhowells@redhat.com>
2014-08-27kbuild: handle module compression while running 'make modules_install'.Bertrand Jacquin1-1/+2
Since module-init-tools (gzip) and kmod (gzip and xz) support compressed modules, it could be useful to include a support for compressing modules right after having them installed. Doing this in kbuild instead of per distro can permit to make this kind of usage more generic. This patch add a Kconfig entry to "Enable loadable module support" menu and let you choose to compress using gzip (default) or xz. Both gzip and xz does not used any extra -[1-9] option since Andi Kleen and Rusty Russell prove no gain is made using them. gzip is called with -n argument to avoid storing original filename inside compressed file, that way we can save some more bytes. On a v3.16 kernel, 'make allmodconfig' generated 4680 modules for a total of 378MB (no strip, no sign, no compress), the following table shows observed disk space gain based on the allmodconfig .config : | time | +-------------+-----------------+ | manual .ko | make | size | percent | compression | modules_install | | gain +-------------+-----------------+------+-------- - | | 18.61s | 378M | GZIP | 3m16s | 3m37s | 102M | 73.41% XZ | 5m22s | 5m39s | 77M | 79.83% The gain for restricted environnement seems to be interesting while uncompress can be time consuming but happens only while loading a module, that is generally done only once. This is fully compatible with signed modules while the signed module is compressed. module-init-tools or kmod handles decompression and provide to other layer the uncompressed but signed payload. Reviewed-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Bertrand Jacquin <beber@meleeweb.net> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2014-08-27modinst: wrap long lines in order to enhance cmd_modules_installBertrand Jacquin1-1/+5
Note: shouldn't we use 'install -D $(2)/$@ $@' instead of mkdir and cp ? Reviewed-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Bertrand Jacquin <beber@meleeweb.net> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2014-06-19kbuild: fix comment in Makefile.modinstOlaf Hering1-1/+1
Signed-off-by: Olaf Hering <olaf@aepfle.de> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2012-11-06modules: don't break modules_install on external modules with no key.Rusty Russell1-1/+2
The script still spits out an error ("Can't read private key") but we don't break modules_install. Reported-by: Bruno Wolff III <bruno@wolff.to> Original-patch-by: Josh Boyer <jwboyer@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2012-10-19kbuild: sign the modules at install timeRusty Russell1-1/+1
Linus deleted the old code and put signing on the install command, I fixed it to extract the keyid and signer-name within sign-file and cleaned up that script now it always signs in-place. Some enthusiast should convert sign-key to perl and pull x509keyid into it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-08-31scripts/Makefile.modpost: error in finding modules from .mod files.이건호1-1/+1
This error may happen when the user's id or path includes .ko string. For example, user's id is xxx.ko and building test.ko module, the test.mod file lists ko name and all object files. /home/xxx.ko/kernel_dev/device/drivers/test.ko /home/xxx.ko/kernel_dev/device/drivers/test_main.o /home/xxx.ko/kernel_dev/device/drivers/test_io.o ... Current Makefile.modpost and Makefile.modinst find and list up not only test.ko but also other object files. because all of object file's path includes .ko string. This is a patch to fix it. Signed-off-by: Gunho Lee <gunho.lee@lge.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2009-01-14Revert "kbuild: strip generated symbols from *.ko"Sam Ravnborg1-2/+1
This reverts commit ad7a953c522ceb496611d127e51e278bfe0ff483. And commit: ("allow stripping of generated symbols under CONFIG_KALLSYMS_ALL") 9bb482476c6c9d1ae033306440c51ceac93ea80c These stripping patches has caused a set of issues: 1) People have reported compatibility issues with binutils due to lack of support for `--strip-unneeded-symbols' with objcopy 2.15.92.0.2 Reported by: Wenji 2) ccache and distcc no longer works as expeced Reported by: Ted, Roland, + others 3) The installed modules increased a lot in size Reported by: Ted, Davej + others Reported-by: Wenji Huang <wenji.huang@oracle.com> Reported-by: "Theodore Ts'o" <tytso@mit.edu> Reported-by: Dave Jones <davej@redhat.com> Reported-by: Roland McGrath <roland@redhat.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2008-12-19kbuild: strip generated symbols from *.koJan Beulich1-1/+2
This patch changes the way __crc_ symbols are being resolved from using ld to do so to using the assembler, thus allowing these symbols to be marked local (the linker creates then as global ones) and hence allow stripping (for modules) or ignoring (for vmlinux) them. While at this, also strip other generated symbols during module installation. One potentially debatable point is the handling of the flags passeed to gcc when translating the intermediate assembly file into an object: passing $(c_flags) unchanged doesn't work as gcc passes --gdwarf2 to gas whenever is sees any -g* option, even for -g0, and despite the fact that the compiler would have already produced all necessary debug info in the C->assembly translation phase. I took the approach of just filtering out all -g* options, but an alternative to such negative filtering might be to have a positive filter which might, in the ideal case allow just all the -Wa,* options to pass through. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2008-01-28kbuild: fix installing external modulesSam Ravnborg1-1/+1
Eric Sandeen <sandeen@redhat.com> reported: Installing external modules is supposed to put them in some path under /lib/modules/<version>/extra/subdir/, but this change: http://linux.bkbits.net:8080/linux-2.6/?PAGE=cset&REV=1.1982.9.23 makes them go under /lib/modules/<version>/extrasubdir (for example, make M=fs/ext3 modules_install puts ext3.ko in /lib/modules/<version>/extrafs/ext3.ko) This was the case only when specifying a trailing slash to M=.. Fixed by removing trailing slash if present so we correctly match dir part of target. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Eric Sandeen <sandeen@redhat.com>
2006-06-24kbuild: add option for stripping modules while installing themTheodore Ts'o1-1/+1
Add option for stripping modules while installing them. This function adds support for stripping modules while they are being installed. CONFIG_DEBUG_KERNEL (which will probably become more popular as developers use kdump) causes the size of the installed modules to grow by a factor of 9 or so. Some kernel package systems solve this problem by stripping the debug information from /lib/modules after running "make modules_install", but that may not work for people who are installing directly into /lib/modules --- root partitions that were sized to handle 16 megs worth of modules may not be quite so happy with 145 megs of modules, so the "make modules_install" never succeeds. This patch allows such users to request modules_install to strip the modules as they are installed. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2006-03-06kbuild: change kbuild to not rely on incorrect GNU make behaviorPaul Smith1-2/+8
The kbuild system takes advantage of an incorrect behavior in GNU make. Once this behavior is fixed, all files in the kernel rebuild every time, even if nothing has changed. This patch ensures kbuild works with both the incorrect and correct behaviors of GNU make. For more details on the incorrect behavior, see: http://lists.gnu.org/archive/html/bug-make/2006-03/msg00003.html Changes in this patch: - Keep all targets that are to be marked .PHONY in a variable, PHONY. - Add .PHONY: $(PHONY) to mark them properly. - Remove any $(PHONY) files from the $? list when determining whether targets are up-to-date or not. Signed-off-by: Paul Smith <psmith@gnu.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2005-07-25kbuild: introduce Kbuild.includeSam Ravnborg1-1/+1
Kbuild.include is a placeholder for definitions originally present in both the top-level Makefile and scripts/Makefile.build. There were a slight difference in the filechk definition, so the most videly used version was kept and usr/Makefile was adopted for this syntax. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> ---
2005-04-16Linux-2.6.12-rc2Linus Torvalds1-0/+29
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!