kernel/.gitignore, branch linux-6.1.y

Remove *.orig pattern from .gitignore

2024-10-17T13:21:15Z

commit 76be4f5a784533c71afbbb1b8f2963ef9e2ee258 upstream. Commit 3f1b0e1f2875 (".gitignore update") added *.orig and *.rej patterns to .gitignore in v2.6.23. The commit message didn't give a rationale. Later on, commit 1f5d3a6b6532 ("Remove *.rej pattern from .gitignore") removed the *.rej pattern in v2.6.26, on the rationale that *.rej files indicated something went really wrong and should not be ignored. The *.rej files are now shown by `git status`, which helps located conflicts when applying patches and lowers the probability that they will go unnoticed. It is however still easy to overlook the *.orig files which slowly polute the source tree. That's not as big of a deal as not noticing a conflict, but it's still not nice. Drop the *.orig pattern from .gitignore to avoid this and help keep the source tree clean. Signed-off-by: Laurent Pinchart [masahiroy@kernel.org: I do not have a strong opinion about this. Perhaps some people may have a different opinion. If you are someone who wants to ignore *.orig, it is likely you would want to do so across all projects. Then, $XDG_CONFIG_HOME/git/ignore would be more suitable for your needs. gitignore(5) suggests, "Patterns which a user wants Git to ignore in all situations generally go into a file specified by core.excludesFile in the user's ~/.gitconfig". Please note that you cannot do the opposite; if *.orig is ignored by the project's .gitignore, you cannot override the decision because $XDG_CONFIG_HOME/git/ignore has a lower priority. If *.orig is sitting on the fence, I'd leave it to the users. ] Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman

Kbuild: add Rust support

2022-09-28T07:02:20Z

Having most of the new files in place, we now enable Rust support in the build system, including `Kconfig` entries related to Rust, the Rust configuration printer and a few other bits. Reviewed-by: Kees Cook Reviewed-by: Nick Desaulniers Tested-by: Nick Desaulniers Reviewed-by: Greg Kroah-Hartman Co-developed-by: Alex Gaynor Signed-off-by: Alex Gaynor Co-developed-by: Finn Behrens Signed-off-by: Finn Behrens Co-developed-by: Adam Bratschi-Kaye Signed-off-by: Adam Bratschi-Kaye Co-developed-by: Wedson Almeida Filho Signed-off-by: Wedson Almeida Filho Co-developed-by: Michael Ellerman Signed-off-by: Michael Ellerman Co-developed-by: Sven Van Asbroeck Signed-off-by: Sven Van Asbroeck Co-developed-by: Gary Guo Signed-off-by: Gary Guo Co-developed-by: Boris-Chengbiao Zhou Signed-off-by: Boris-Chengbiao Zhou Co-developed-by: Boqun Feng Signed-off-by: Boqun Feng Co-developed-by: Douglas Su Signed-off-by: Douglas Su Co-developed-by: Dariusz Sosnowski Signed-off-by: Dariusz Sosnowski Co-developed-by: Antonio Terceiro Signed-off-by: Antonio Terceiro Co-developed-by: Daniel Xu Signed-off-by: Daniel Xu Co-developed-by: Björn Roy Baron Signed-off-by: Björn Roy Baron Co-developed-by: Martin Rodriguez Reboredo Signed-off-by: Martin Rodriguez Reboredo Signed-off-by: Miguel Ojeda

rust: add `.rustfmt.toml`

2022-09-28T07:02:20Z

This is the configuration file for the `rustfmt` tool. `rustfmt` is a tool for formatting Rust code according to style guidelines. It is very commonly used across Rust projects. The default configuration options are used. Reviewed-by: Kees Cook Co-developed-by: Alex Gaynor Signed-off-by: Alex Gaynor Co-developed-by: Wedson Almeida Filho Signed-off-by: Wedson Almeida Filho Signed-off-by: Miguel Ojeda

scripts: add `generate_rust_analyzer.py`

2022-09-28T07:02:06Z

The `generate_rust_analyzer.py` script generates the configuration file (`rust-project.json`) for rust-analyzer. rust-analyzer is a modular compiler frontend for the Rust language. It provides an LSP server which can be used in editors such as VS Code, Emacs or Vim. Reviewed-by: Kees Cook Co-developed-by: Alex Gaynor Signed-off-by: Alex Gaynor Co-developed-by: Finn Behrens Signed-off-by: Finn Behrens Co-developed-by: Wedson Almeida Filho Signed-off-by: Wedson Almeida Filho Co-developed-by: Gary Guo Signed-off-by: Gary Guo Co-developed-by: Boris-Chengbiao Zhou Signed-off-by: Boris-Chengbiao Zhou Co-developed-by: Björn Roy Baron Signed-off-by: Björn Roy Baron Signed-off-by: Miguel Ojeda

kbuild: split the second line of .mod into .usyms

2022-05-07T18:16:59Z

The *.mod files have two lines; the first line lists the member objects of the module, and the second line, if CONFIG_TRIM_UNUSED_KSYMS=y, lists the undefined symbols. Currently, we generate *.mod after constructing composite modules, otherwise, we cannot compute the second line. No prerequisite is required to print the first line. They are orthogonal. Splitting them into separate commands will ease further cleanups. This commit splits the list of undefined symbols out to *.usyms files. Previously, the list of undefined symbols ended up with a very long line, but now it has one symbol per line. Use sed like we did before commit 7d32358be8ac ("kbuild: avoid split lines in .mod files"). Signed-off-by: Masahiro Yamada Reviewed-by: Nicolas Schier

.gitignore: ignore only top-level modules.builtin

2021-05-01T15:43:35Z

modules.builtin used to be created in every directory. Since commit 8b41fc4454e3 ("kbuild: create modules.builtin without Makefile.modbuiltin or tristate.conf"), modules.builtin is created only in the top directory. Add the '/' prefix so that it matches to only the modules.builtin located in the top directory. It has been more than one year since that change. I hope this will not flood 'Untracked files' of 'git status'. Signed-off-by: Masahiro Yamada

.gitignore: move tags and TAGS close to other tag files

2021-05-01T15:43:35Z

For consistency, move tags and TAGS close to the cscope and GNU Global patterns. I removed the '/' prefix in case somebody wants to manually create tag files in sub-directories. Signed-off-by: Masahiro Yamada

kbuild: generate Module.symvers only when vmlinux exists

2021-04-24T20:17:02Z

The external module build shows the following warning if Module.symvers is missing in the kernel tree. WARNING: Symbol version dump "Module.symvers" is missing. Modules may not have dependencies or modversions. I think this is an important heads-up because the resulting modules may not work as expected. This happens when you did not build the entire kernel tree, for example, you might have prepared the minimal setups for external modules by 'make defconfig && make modules_preapre'. A problem is that 'make modules' creates Module.symvers even without vmlinux. In this case, that warning is suppressed since Module.symvers already exists in spite of its incomplete content. The incomplete (i.e. invalid) Module.symvers should not be created. This commit changes the second pass of modpost to dump symbols into modules-only.symvers. The final Module.symvers is created by concatenating vmlinux.symvers and modules-only.symvers if both exist. Module.symvers is supposed to collect symbols from both vmlinux and modules. It might be a bit confusing, and I am not quite sure if it is an official interface, but presumably it is difficult to rename it because some tools (e.g. kmod) parse it. Signed-off-by: Masahiro Yamada

kbuild: add CONFIG_VMLINUX_MAP expert option

2021-04-24T20:12:26Z

It can be quite useful to have ld emit a link map file, in order to debug or verify that special sections end up where they are supposed to, and to see what LD_DEAD_CODE_DATA_ELIMINATION manages to get rid of. The only reason I'm not just adding this unconditionally is that the .map file can be rather large (several MB), and that's a waste of space when one isn't interested in these things. Also make it depend on CONFIG_EXPERT. Signed-off-by: Rasmus Villemoes Signed-off-by: Masahiro Yamada

Merge tag 'clang-lto-v5.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2021-02-23T17:28:51Z

Pull clang LTO updates from Kees Cook: "Clang Link Time Optimization. This is built on the work done preparing for LTO by arm64 folks, tracing folks, etc. This includes the core changes as well as the remaining pieces for arm64 (LTO has been the default build method on Android for about 3 years now, as it is the prerequisite for the Control Flow Integrity protections). While x86 LTO enablement is done, it depends on some pending objtool clean-ups. It's possible that I'll send a "part 2" pull request for LTO that includes x86 support. For merge log posterity, and as detailed in commit dc5723b02e52 ("kbuild: add support for Clang LTO"), here is the lt;dr to do an LTO build: make LLVM=1 LLVM_IAS=1 defconfig scripts/config -e LTO_CLANG_THIN make LLVM=1 LLVM_IAS=1 (To do a cross-compile of arm64, add "CROSS_COMPILE=aarch64-linux-gnu-" and "ARCH=arm64" to the "make" command lines.) Summary: - Clang LTO build infrastructure and arm64-specific enablement (Sami Tolvanen) - Recursive build CC_FLAGS_LTO fix (Alexander Lobakin)" * tag 'clang-lto-v5.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: kbuild: prevent CC_FLAGS_LTO self-bloating on recursive rebuilds arm64: allow LTO to be selected arm64: disable recordmcount with DYNAMIC_FTRACE_WITH_REGS arm64: vdso: disable LTO drivers/misc/lkdtm: disable LTO for rodata.o efi/libstub: disable LTO scripts/mod: disable LTO for empty.c modpost: lto: strip .lto from module names PCI: Fix PREL32 relocations for LTO init: lto: fix PREL32 relocations init: lto: ensure initcall ordering kbuild: lto: add a default list of used symbols kbuild: lto: merge module sections kbuild: lto: limit inlining kbuild: lto: fix module versioning kbuild: add support for Clang LTO tracing: move function tracer options to Kconfig