IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Every time a config file is loaded (either by clicking the "Load" button
or selecting "File" -> "Load" from the menu), a new list is appended to
the pane.
The current tree needs to be cleared by calling gtk_tree_store_clear().
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Use the KBUILD_IMAGE variable to determine the right kernel image to
install and install compressed images to /boot/vmlinuz-$version like the
'make install' target already does.
Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
With commit 4b0bf9a01270 ("riscv: compat_vdso: install compat_vdso.so.dbg
to /lib/modules/*/vdso/") applied, all debug VDSO files are installed in
$(MODLIB)/vdso/.
Simplify the installation rule.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Currently, Kbuild produces inconsistent results in some cases.
You can do an interesting experiment using the --shuffle option, which
is supported by GNU Make 4.4 or later.
Set CONFIG_KVM_INTEL=y and CONFIG_KVM_AMD=m (or vice versa), and repeat
incremental builds w/wo --shuffle=reverse.
$ make
[ snip ]
CC arch/x86/kvm/kvm-asm-offsets.s
$ make --shuffle=reverse
[ snip ]
CC [M] arch/x86/kvm/kvm-asm-offsets.s
$ make
[ snip ]
CC arch/x86/kvm/kvm-asm-offsets.s
arch/x86/kvm/kvm-asm-offsets.s is rebuilt every time w/wo the [M] marker.
arch/x86/kvm/kvm-asm-offsets.s is built as built-in when it is built as
a prerequisite of arch/x86/kvm/kvm-intel.o, which is built-in.
arch/x86/kvm/kvm-asm-offsets.s is built as modular when it is built as
a prerequisite of arch/x86/kvm/kvm-amd.o, which is a module.
Another odd example is single target builds.
When CONFIG_LKDTM=m, drivers/misc/lkdtm/rodata.o can be built as
built-in or modular, depending on how it is built.
$ make drivers/misc/lkdtm/lkdtm.o
[ snip ]
CC [M] drivers/misc/lkdtm/rodata.o
$ make drivers/misc/lkdtm/rodata.o
[ snip ]
CC drivers/misc/lkdtm/rodata.o
drivers/misc/lkdtm/rodata.o is built as modular when it is built as a
prerequisite of another, but built as built-in when it is a final
target.
The same thing happens to drivers/memory/emif-asm-offsets.s when
CONFIG_TI_EMIF_SRAM=m.
$ make drivers/memory/ti-emif-sram.o
[ snip ]
CC [M] drivers/memory/emif-asm-offsets.s
$ make drivers/memory/emif-asm-offsets.s
[ snip ]
CC drivers/memory/emif-asm-offsets.s
This is because the part-of-module=y flag defined for the modules is
inherited by its prerequisites.
Target-specific variables are likely intended only for local use.
This commit adds 'private' to them.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>
Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for
checked-in source files. It is merely a convention without any functional
difference. In fact, $(obj) and $(src) are exactly the same, as defined
in scripts/Makefile.build:
src := $(obj)
When the kernel is built in a separate output directory, $(src) does
not accurately reflect the source directory location. While Kbuild
resolves this discrepancy by specifying VPATH=$(srctree) to search for
source files, it does not cover all cases. For example, when adding a
header search path for local headers, -I$(srctree)/$(src) is typically
passed to the compiler.
This introduces inconsistency between upstream and downstream Makefiles
because $(src) is used instead of $(srctree)/$(src) for the latter.
To address this inconsistency, this commit changes the semantics of
$(src) so that it always points to the directory in the source tree.
Going forward, the variables used in Makefiles will have the following
meanings:
$(obj) - directory in the object tree
$(src) - directory in the source tree (changed by this commit)
$(objtree) - the top of the kernel object tree
$(srctree) - the top of the kernel source tree
Consequently, $(srctree)/$(src) in upstream Makefiles need to be replaced
with $(src).
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for
checked-in source files. It is merely a convention without any functional
difference. In fact, $(obj) and $(src) are exactly the same, as defined
in scripts/Makefile.build:
src := $(obj)
Before changing the semantics of $(src) in the next commit, this commit
replaces $(obj)/ with $(src)/ in pattern rules where the prerequisite
might be a generated file.
C, assembly, Rust, and DTS files are sometimes generated by tools, so
they could be either generated files or real sources. The $(obj)/ prefix
works for both cases with the help of VPATH.
As mentioned above, $(obj) and $(src) are the same at this point, hence
this commit has no functional change.
I did not modify scripts/Makefile.userprogs because there is no use
case where userspace C files are generated.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmY39LkeHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGaB8H+wWcwT1O7K2SQx1a
sHDYJSXfbjgShS7Wt+gbDNvhGJqG/5FkpHyBmBKUdElZs8QMf21GAbIfJvzcNThA
g+FakIMjfhNH/dr6TJXHWbb2NZV67exDbbuaQDyMhNhIZqil4BH/OEPbLYIdquvm
/HDGFB/whVoHVC+Ug8esEOL3Uy+rizBDlsT/K4ZgpOC3TuUmlRpptSVACwjcCGXM
PFKyyTIr0ZnKcz3+4yTEtpDFm6e/ujxMwM66GBCgmPaZ3lJp5ruY3kGpBTmSyoqV
Rh3CQlIhBo8gwlAx/yQXfxEZomhxT6DfRpc6s/1W0J1UZN/j2pYy056OYyckG32c
uQ9ujxQ=
=M0wP
-----END PGP SIGNATURE-----
Merge 6.9-rc7 into char-misc-testing
We need the char-misc changes in here as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Directly read the current CPU number from the kgdb_active variable.
Before, the active CPU was obtained through the current task, which
required searching the task list for the pid of GDB's selected thread.
Obtaining the pid was buggy: GDB may use selected_thread().ptid[1] (LWPID)
instead of .ptid[2] (TID) to store the threads pid; see
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Threads-In-Python.html
As a result, the detection could return the wrong CPU number, leading to
incorrect results for $lx_per_cpu and $lx_current.
As a side effect, the patch significantly speeds up $lx_per_cpu and
$lx_current in KGDB by avoiding the task-list iteration.
Link: https://lkml.kernel.org/r/20240425153501.749966-5-mail@florommel.de
Signed-off-by: Florian Rommel <mail@florommel.de>
Cc: Andrew Jones <ajones@ventanamicro.com>
Cc: Deepak Gupta <debug@rivosinc.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Kieran Bingham <kbingham@kernel.org>
Cc: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
Cc: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
get_thread_info ($lx_thread_info) only accepted a dereferenced task
parameter. Passing a pointer to a task_struct (like $lx_per_cpu does with
KGDB) threw an exception.
With this patch, both (dereferenced values and pointers) are accepted.
Before (on x86, KGDB):
>>> p $lx_per_cpu(cpu_info)
Traceback (most recent call last):
File "./scripts/gdb/linux/cpus.py", line 158, in invoke
return per_cpu(var_ptr, cpu)
^^^^^^^^^^^^^^^^^^^^^
File "./scripts/gdb/linux/cpus.py", line 42, in per_cpu
cpu = get_current_cpu()
^^^^^^^^^^^^^^^^^
File "./scripts/gdb/linux/cpus.py", line 33, in get_current_cpu
return tasks.get_thread_info(tasks.get_task_by_pid(tid))['cpu']
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "./scripts/gdb/linux/tasks.py", line 88, in get_thread_info
if task.type.fields()[0].type == thread_info_type.get_type():
~~~~~~~~~~~~~~~~~~^^^
IndexError: list index out of range
Link: https://lkml.kernel.org/r/20240425153501.749966-4-mail@florommel.de
Signed-off-by: Florian Rommel <mail@florommel.de>
Cc: Andrew Jones <ajones@ventanamicro.com>
Cc: Deepak Gupta <debug@rivosinc.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Kieran Bingham <kbingham@kernel.org>
Cc: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
Cc: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Before, the script tried to get the address by constructing a pointer to
the parameter (by name). However, since GDB now passes the parameter as a
GdbValue, we cannot get its name. Instead, we retrieve the address
through GdbValue's address attribute.
Before:
>>> p $lx_per_cpu(cpu_info)
Traceback (most recent call last):
File "./scripts/gdb/linux/cpus.py", line 152, in invoke
var_ptr = gdb.parse_and_eval("&" + var_name.string())
^^^^^^^^^^^^^^^^^
gdb.error: Trying to read string with inappropriate type `struct cpuinfo_x86'.
Link: https://lkml.kernel.org/r/20240425153501.749966-3-mail@florommel.de
Signed-off-by: Florian Rommel <mail@florommel.de>
Cc: Andrew Jones <ajones@ventanamicro.com>
Cc: Deepak Gupta <debug@rivosinc.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Kieran Bingham <kbingham@kernel.org>
Cc: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
Cc: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Patch series "scripts/gdb: Fixes for $lx_current and $lx_per_cpu".
This series fixes several bugs in the GDB scripts related to the
$lx_current and $lx_per_cpu functions. The changes were tested with GDB
10, 11, 12, 13, and 14.
Patch 1 fixes false-negative results when probing for KGDB
Patch 2 fixes the $lx_per_cpu function, which is currently non-functional
in QEMU-GDB and KGDB.
Patch 3 fixes an additional bug in $lx_per_cpu that occurs with KGDB.
Patch 4 fixes the incorrect detection of the current CPU number in KGDB,
which silently breaks $lx_per_cpu and $lx_current.
This patch (of 4):
The KGDB probe function sometimes failed to detect KGDB for SMP machines
as it assumed that task 2 (kthreadd) is running on CPU 0, which is not
necessarily the case. Now, the detection is agnostic to kthreadd's CPU.
Link: https://lkml.kernel.org/r/20240425153501.749966-1-mail@florommel.de
Link: https://lkml.kernel.org/r/20240425153501.749966-2-mail@florommel.de
Signed-off-by: Florian Rommel <mail@florommel.de>
Cc: Andrew Jones <ajones@ventanamicro.com>
Cc: Deepak Gupta <debug@rivosinc.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Kieran Bingham <kbingham@kernel.org>
Cc: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
Cc: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
scripts/Makefile.lib is included not only from scripts/Makefile.build
but also from scripts/Makefile.{vmlinux,modfinal} for building generated
C files.
In scripts/Makefile.{vmlinux,modfinal}, $(obj) and $(src) are empty.
Therefore, the header include paths:
-I $(srctree)/$(src) -I $(objtree)/$(obj)
... become meaningless code:
-I $(srctree)/ -I $(objtree)/
Add these paths only when 'obj' and 'src' are defined.
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/oe-kbuild-all/202404170634.BlqTaYA0-lkp@intel.com/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>
Fixed: WARNING: Inline literal start-string without end-string in
Documentation/core-api/workqueue.rst
Added "*" in $type_constants2 in kernel-doc script to include "*" in the
conversion to hightlights.
Previously: %WQ_* --> ``WQ_``*
After Changes: %WQ_* --> ``WQ_*``
Need for the fix: ``* is not recognized as a valid end-string for inline
literal.
Link: https://lore.kernel.org/linux-doc/640114d2-5780-48c3-a294-c0eba230f984@gmail.com
Signed-off-by: Utkarsh Tripathi <utripathi2002@gmail.com>
Suggested-by: Akira Yokosawa <akiyks@gmail.com>
Reviewed-by: Akira Yokosawa <akiyks@gmail.com>
Link: https://lore.kernel.org/r/20240503182650.7761-1-utripathi2002@gmail.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
We should not use any CONFIG switches in uapi headers since
these only work during kernel compilation. They are not defined
for userspace. Let's use the __mcoldfire__ switch from the
compiler here instead.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
This is the next upgrade to the Rust toolchain, from 1.77.1 to 1.78.0
(i.e. the latest) [1].
See the upgrade policy [2] and the comments on the first upgrade in
commit 3ed03f4da06e ("rust: upgrade to Rust 1.68.2").
It is much smaller than previous upgrades, since the `alloc` fork was
dropped in commit 9d0441bab775 ("rust: alloc: remove our fork of the
`alloc` crate") [3].
# Unstable features
There have been no changes to the set of unstable features used in
our own code. Therefore, the only unstable features allowed to be used
outside the `kernel` crate is still `new_uninit`.
However, since we finally dropped our `alloc` fork [3], all the unstable
features used by `alloc` (~30 language ones, ~60 library ones) are not
a concern anymore. This reduces the maintenance burden, increases the
chances of new compiler versions working without changes and gets us
closer to the goal of supporting several compiler versions.
It also means that, ignoring non-language/library features, we are
currently left with just the few language features needed to implement the
kernel `Arc`, the `new_uninit` library feature, the `compiler_builtins`
marker and the few `no_*` `cfg`s we pass when compiling `core`/`alloc`.
Please see [4] for details.
# Required changes
## LLVM's data layout
Rust 1.77.0 (i.e. the previous upgrade) introduced a check for matching
LLVM data layouts [5]. Then, Rust 1.78.0 upgraded LLVM's bundled major
version from 17 to 18 [6], which changed the data layout in x86 [7]. Thus
update the data layout in our custom target specification for x86 so
that the compiler does not complain about the mismatch:
error: data-layout for target `target-5559158138856098584`,
`e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128`,
differs from LLVM target's `x86_64-linux-gnu` default layout,
`e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128`
In the future, the goal is to drop the custom target specifications.
Meanwhile, if we want to support other LLVM versions used in `rustc`
(e.g. for LTO), we will need to add some extra logic (e.g. conditional on
LLVM's version, or extracting the data layout from an existing built-in
target specification).
## `unused_imports`
Rust's `unused_imports` lint covers both unused and redundant imports.
Now, in 1.78.0, the lint detects more cases of redundant imports [8].
Thus one of the previous patches cleaned them up.
## Clippy's `new_without_default`
Clippy now suggests to implement `Default` even when `new()` is `const`,
since `Default::default()` may call `const` functions even if it is not
`const` itself [9]. Thus one of the previous patches implemented it.
# Other changes in Rust
Rust 1.78.0 introduced `feature(asm_goto)` [10] [11]. This feature was
discussed in the past [12].
Rust 1.78.0 introduced `feature(const_refs_to_static)` [13] to allow
referencing statics in constants and extended `feature(const_mut_refs)`
to allow raw mutable pointers in constants. Together, this should cover
the kernel's `VTABLE` use case. In fact, the implementation [14] in
upstream Rust added a test case for it [15].
Rust 1.78.0 with debug assertions enabled (i.e. `-Cdebug-assertions=y`,
kernel's `CONFIG_RUST_DEBUG_ASSERTIONS=y`) now always checks all unsafe
preconditions, though without a way to opt-out for particular cases [16].
It would be ideal to have a way to selectively disable certain checks
per-call site for this one (i.e. not just per check but for particular
instances of a check), even if the vast majority of the checks remain
in place [17].
Rust 1.78.0 also improved a couple issues we reported when giving feedback
for the new `--check-cfg` feature [18] [19].
# `alloc` upgrade and reviewing
As mentioned above, compiler upgrades will not update `alloc` anymore,
since we dropped our `alloc` fork [3].
Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1780-2024-05-02 [1]
Link: https://rust-for-linux.com/rust-version-policy [2]
Link: https://lore.kernel.org/rust-for-linux/20240328013603.206764-1-wedsonaf@gmail.com/ [3]
Link: https://github.com/Rust-for-Linux/linux/issues/2 [4]
Link: https://github.com/rust-lang/rust/pull/120062 [5]
Link: https://github.com/rust-lang/rust/pull/120055 [6]
Link: https://reviews.llvm.org/D86310 [7]
Link: https://github.com/rust-lang/rust/pull/117772 [8]
Link: https://github.com/rust-lang/rust-clippy/pull/10903 [9]
Link: https://github.com/rust-lang/rust/pull/119365 [10]
Link: https://github.com/rust-lang/rust/issues/119364 [11]
Link: https://lore.kernel.org/rust-for-linux/ZWipTZysC2YL7qsq@Boquns-Mac-mini.home/ [12]
Link: https://github.com/rust-lang/rust/issues/119618 [13]
Link: https://github.com/rust-lang/rust/pull/120932 [14]
Link: https://github.com/rust-lang/rust/pull/120932/files#diff-e6fc1622c46054cd46b1d225c5386c5554564b3b0fa8a03c2dc2d8627a1079d9 [15]
Link: https://github.com/rust-lang/rust/issues/120969 [16]
Link: https://github.com/Rust-for-Linux/linux/issues/354 [17]
Link: https://github.com/rust-lang/rust/pull/121202 [18]
Link: https://github.com/rust-lang/rust/pull/121237 [19]
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20240401212303.537355-4-ojeda@kernel.org
[ Added a few more details and links I mentioned in the list. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
'struct lcd_ops' is not modified by core code.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Suggested-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Acked-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20240424-video-backlight-lcd-ops-v2-19-1aaa82b07bc6@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Cross-merge networking fixes after downstream PR.
Conflicts:
include/linux/filter.h
kernel/bpf/core.c
66e13b615a0c ("bpf: verifier: prevent userspace memory access")
d503a04f8bc0 ("bpf: Add support for certain atomics in bpf_arena to x86 JIT")
https://lore.kernel.org/all/20240429114939.210328b0@canb.auug.org.au/
No adjacent changes.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
As mentioned in "Assumption:", current grep expression can't catch
font files whose names are changed from upstream "Noto CJK fonts".
To avoid false negatives, use command of the form:
fc-list : file family variable
, where ":" works as a wildcard pattern.
Variable fonts can be detected by filtering the output with
"variable=True" and "Noto CJK" font-family variants.
Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/c62ba2e6-c124-4e91-8011-cb1da408a3c5@gmail.com
This flag is set to symbols that are not intended to be written
to the .config file.
Since commit b75b0a819af9 ("kconfig: change defconfig_list option to
environment variable"), SYMBOL_NO_WRITE is only set to choices.
Therefore, (sym->flags & SYMBOL_NO_WRITE) is equivalent to
sym_is_choice(sym). This flag is no longer necessary.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The 'choice' statement is primarily used to exclusively select one
option, but the 'optional' property allows all entries to be disabled.
In the following example, both A and B can be disabled simultaneously:
choice
prompt "choose A, B, or nothing"
optional
config A
bool "A"
config B
bool "B"
endchoice
You can achieve the equivalent outcome by other means.
A common solution is to add another option to guard the choice block.
In the following example, you can set ENABLE_A_B_CHOICE=n to disable
the entire choice block:
choice
prompt "choose A or B"
depends on ENABLE_A_B_CHOICE
config A
bool "A"
config B
bool "B"
endchoice
Another approach is to insert one more entry:
choice
prompt "choose A, B, or disable both"
config A
bool "A"
config B
bool "B"
config DISABLE_A_AND_B
bool "choose this to disable both A and B"
endchoice
Some real examples are DEBUG_INFO_NONE, INITRAMFS_COMPRESSION_NONE,
LTO_NONE, etc.
The 'optional' property is even more unnecessary for a tristate choice.
Without the 'optional' property, you can disable A and B; you can set
'm' in the choice prompt, and disable A and B individually:
choice
prompt "choose one built-in or make them modular"
config A
tristate "A"
config B
tristate "B"
endchoice
In conclusion, the 'optional' property was unneeded.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>
All symbols except choices have a name.
Previously, choices were allowed to have a name, but commit c83f020973bc
("kconfig: remove named choice support") eliminated that possibility.
Now, it is easy to distinguish choices from normal symbols; if the name
is NULL, it is a choice.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>
Given KBUILD_IMAGE properly set in arch/*/Makefile, the default case
should work in most scenarios. The only oddity is the naming of the
copy destination, vmlinux-kbuild-${KERNELRELEASE}. Let's rename it
to vmlinuz-${KERNELRELEASE} because the kernel is often compressed.
Remove the warning to avoid unnecessary patch submissions when the
default case suffices.
Remove the x86 case, which is now equivalent to the default.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
All symbols except choices have a name.
child->sym->name never becomes NULL inside choice blocks.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Use menu_for_each_entry() to traverse the menu tree instead of
implementing similar logic in each function.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Several functions require traversing menu entries sequentially. This
commit introduces some helpers to simplify such operations.
The menu_next() function facilitates depth-first traversal:
1. Descend to the child level if the current menu has one
2. Move to the next sibling at the same level if available
3. Ascend to the parent level if there is no more child or sibling
The menu_for_each_sub_entry() macro iterates over all submenu entries
using depth-first traverse.
The menu_for_each_entry() macro is the same, but over all menu entries.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
scripts/package/buildtar checks some kernel packages, and copies the
first image found. This may potentially produce an inconsistent (and
possibly wrong) package.
For instance, the for-loop for arm64 checks Image.{bz2,gz,lz4,lzma,lzo},
and vmlinuz.efi, then copies the first image found, which might be a
stale image created in a previous build.
When CONFIG_EFI_ZBOOT is enabled in the pristine source tree,
'make ARCH=arm64 tar-pkg' will build and copy vmlinuz.efi. This is the
expected behavior.
If you build the kernel with CONFIG_EFI_ZBOOT disabled, Image.gz will
be created, which will remain in the tree until you run 'make clean'.
Even if CONFIG_EFI_ZBOOT is turned on later, 'make ARCH=arm64 tar-pkg'
will copy stale Image.gz instead of the latest vmlinuz.efi, as Image.gz
takes precedence over vmlinuz.efi.
In summary, the code "[ -f ... ] && cp" does not consistently produce
the desired outcome.
Other packaging targets are deterministic; deb-pkg and rpm-pkg copies
${KBUILD_IMAGE}, which is determined by CONFIG options.
I removed [ -f ... ] checks from x86, alpha, parisc, and the default
because they have a single kernel image to copy. If it is missing, it
should be an error.
I did not modify the code for mips, arm64, riscv. Instead, I left some
comments. Eventually, someone may fix the code, or at the very least,
it may discourage the copy-pasting of incorrect code to another
architecture.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Running dtbs_check and dt_compatible_check targets really only depend
on processed-schema.json, but the dependency is 'dt_binding_check'. That
was sort worked around with the CHECK_DT_BINDING variable in order to
skip some of the work that 'dt_binding_check' does. It still runs the
full checks of the schemas which is not necessary and adds 10s of
seconds to the build time. That's significant when checking only a few
DTBs and with recent changes that have improved the validation time by
6-7x.
Add a new target, dt_binding_schema, which just builds
processed-schema.json and can be used as the dependency for other
targets. The scripts_dtc dependency isn't needed either as the examples
aren't built for it.
Signed-off-by: Rob Herring <robh@kernel.org>
Tested-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
The rust modules work on 64-bit RISC-V, with no twiddling required.
Select HAVE_RUST and provide the required flags to kbuild so that the
modules can be used. The Makefile and Kconfig changes are lifted from
work done by Miguel in the Rust-for-Linux tree, hence his authorship.
Following the rabbit hole, the Makefile changes originated in a script,
created based on config files originally added by Gary, hence his
co-authorship.
32-bit is broken in core rust code, so support is limited to 64-bit:
ld.lld: error: undefined symbol: __udivdi3
As 64-bit RISC-V is now supported, add it to the arch support table.
Co-developed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Co-developed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240409-silencer-book-ce1320f06aab@spud
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
- Soundness: make internal functions generated by the 'module!' macro
inaccessible, do not implement 'Zeroable' for 'Infallible' and
require 'Send' for the 'Module' trait.
- Build: avoid errors with "empty" files and workaround 'rustdoc' ICE.
- Kconfig: depend on '!CFI_CLANG' and avoid selecting 'CONSTRUCTORS'.
- Code docs: remove non-existing key from 'module!' macro example.
- Docs: trivial rendering fix in arch table.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEPjU5OPd5QIZ9jqqOGXyLc2htIW0FAmYtL80ACgkQGXyLc2ht
IW3MvA//SwYchw/ydVO/OrDV/tkH4E7vjFYIUm+AJvOpaBJUMGusFpdn0gtl7bQ8
x4z09Y96Hn9yweejcsUvLSEyx8JBhTZ+z5/hL5FAw8atBUWnoSCoNdR+CJs/10aE
3hRt/Zts5LEdy0CuTb3S8GOJkMCa9RE9X0XPu6M8xIq7oU4RlOl2OANy2JDT8QJq
A8nMESOvBc1SmWimc7gl1rBO9HmRkdSxalRDuAyDv3JCTgynoJFftRVOZfDhJgZ2
gIX0c9rLTNzxPmykAC0Ck4+WzU6/h3nPoZauUPjssV4KK1UgrSSveWoRBLA/Js+L
GVOvb6VCthZj77wAYhojc7erjAEzrxHQ2aGlfZhQntzxIs3eagZEFE+y7HwId9LZ
ybGaATUXz9oj6Vfh/LReM54SKbzBYzdiVO0HwJQE2CQuZjjEn7KxMtl0Vq+SRO+I
Fa6Cd9qOxFeUv7e8xym5CVGEW2KokJEsroRmINusZJ2dk0LxLNDl9f6IAAKhUuJo
vGggMBn1FvYJLmMtDGFYacZr3B42Xn0ANd30Lf3uOxvpSDxeghA3A7LoyXdzM2Qu
twf6nvFOx7h1a68fbmbusnJY8G999t4Inc3htTAoFgYZiQ4UzLBLNEsFtlq4xmz8
DNjfmFMAOQis2dzBkyVXQzKgRuUqK4UZpQFuBq9EqVT469RMsro=
=WaUJ
-----END PGP SIGNATURE-----
Merge tag 'rust-fixes-6.9' of https://github.com/Rust-for-Linux/linux
Pull Rust fixes from Miguel Ojeda:
- Soundness: make internal functions generated by the 'module!' macro
inaccessible, do not implement 'Zeroable' for 'Infallible' and
require 'Send' for the 'Module' trait.
- Build: avoid errors with "empty" files and workaround 'rustdoc' ICE.
- Kconfig: depend on '!CFI_CLANG' and avoid selecting 'CONSTRUCTORS'.
- Code docs: remove non-existing key from 'module!' macro example.
- Docs: trivial rendering fix in arch table.
* tag 'rust-fixes-6.9' of https://github.com/Rust-for-Linux/linux:
rust: remove `params` from `module` macro example
kbuild: rust: force `alloc` extern to allow "empty" Rust files
kbuild: rust: remove unneeded `@rustc_cfg` to avoid ICE
rust: kernel: require `Send` for `Module` implementations
rust: phy: implement `Send` for `Registration`
rust: make mutually exclusive with CFI_CLANG
rust: macros: fix soundness issue in `module!` macro
rust: init: remove impl Zeroable for Infallible
docs: rust: fix improper rendering in Arch Support page
rust: don't select CONSTRUCTORS
Introduce CONFIG_MEM_ALLOC_PROFILING which provides definitions to easily
instrument memory allocators. It registers an "alloc_tags" codetag type
with /proc/allocinfo interface to output allocation tag information when
the feature is enabled.
CONFIG_MEM_ALLOC_PROFILING_DEBUG is provided for debugging the memory
allocation profiling instrumentation.
Memory allocation profiling can be enabled or disabled at runtime using
/proc/sys/vm/mem_profiling sysctl when CONFIG_MEM_ALLOC_PROFILING_DEBUG=n.
CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT enables memory allocation
profiling by default.
[surenb@google.com: Documentation/filesystems/proc.rst: fix allocinfo title]
Link: https://lkml.kernel.org/r/20240326073813.727090-1-surenb@google.com
[surenb@google.com: do limited memory accounting for modules with ARCH_NEEDS_WEAK_PER_CPU]
Link: https://lkml.kernel.org/r/20240402180933.1663992-2-surenb@google.com
[klarasmodin@gmail.com: explicitly include irqflags.h in alloc_tag.h]
Link: https://lkml.kernel.org/r/20240407133252.173636-1-klarasmodin@gmail.com
[surenb@google.com: fix alloc_tag_init() to prevent passing NULL to PTR_ERR()]
Link: https://lkml.kernel.org/r/20240417003349.2520094-1-surenb@google.com
Link: https://lkml.kernel.org/r/20240321163705.3067592-14-surenb@google.com
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Co-developed-by: Kent Overstreet <kent.overstreet@linux.dev>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Signed-off-by: Klara Modin <klarasmodin@gmail.com>
Tested-by: Kees Cook <keescook@chromium.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Alex Gaynor <alex.gaynor@gmail.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Andreas Hindborg <a.hindborg@samsung.com>
Cc: Benno Lossin <benno.lossin@proton.me>
Cc: "Björn Roy Baron" <bjorn3_gh@protonmail.com>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Dennis Zhou <dennis@kernel.org>
Cc: Gary Guo <gary@garyguo.net>
Cc: Miguel Ojeda <ojeda@kernel.org>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Wedson Almeida Filho <wedsonaf@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
These symbols are used to denote section boundaries: by always including
them we can unify loading sections from modules with loading built-in
sections, which leads to some significant cleanup.
Link: https://lkml.kernel.org/r/20240321163705.3067592-5-surenb@google.com
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Tested-by: Kees Cook <keescook@chromium.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Alex Gaynor <alex.gaynor@gmail.com>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: Andreas Hindborg <a.hindborg@samsung.com>
Cc: Benno Lossin <benno.lossin@proton.me>
Cc: "Björn Roy Baron" <bjorn3_gh@protonmail.com>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Dennis Zhou <dennis@kernel.org>
Cc: Gary Guo <gary@garyguo.net>
Cc: Miguel Ojeda <ojeda@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Wedson Almeida Filho <wedsonaf@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Memory profiling introduces macros as hooks for function-level allocation
profiling[1]. Memory allocation functions that are profiled are named
like xyz_alloc() for API access to the function. xyz_alloc() then calls
xyz_alloc_noprof() to do the allocation work.
The kernel-doc comments for the memory allocation functions are introduced
with the xyz_alloc() function names but the function implementations are
the xyz_alloc_noprof() names. This causes kernel-doc warnings for
mismatched documentation and function prototype names. By dropping the
"_noprof" part of the function name, the kernel-doc function name matches
the function prototype name, so the warnings are resolved.
[1] https://lore.kernel.org/all/20240321163705.3067592-1-surenb@google.com/
Link: https://lkml.kernel.org/r/20240326054149.2121-1-rdunlap@infradead.org
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Closes: https://lore.kernel.org/all/20240325123603.1bdd6588@canb.auug.org.au/
Tested-by: Suren Baghdasaryan <surenb@google.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Kent Overstreet <kent.overstreet@linux.dev>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
If one attempts to build an essentially empty file somewhere in the
kernel tree, it leads to a build error because the compiler does not
recognize the `new_uninit` unstable feature:
error[E0635]: unknown feature `new_uninit`
--> <crate attribute>:1:9
|
1 | feature(new_uninit)
| ^^^^^^^^^^
The reason is that we pass `-Zcrate-attr='feature(new_uninit)'` (together
with `-Zallow-features=new_uninit`) to let non-`rust/` code use that
unstable feature.
However, the compiler only recognizes the feature if the `alloc` crate
is resolved (the feature is an `alloc` one). `--extern alloc`, which we
pass, is not enough to resolve the crate.
Introducing a reference like `use alloc;` or `extern crate alloc;`
solves the issue, thus this is not seen in normal files. For instance,
`use`ing the `kernel` prelude introduces such a reference, since `alloc`
is used inside.
While normal use of the build system is not impacted by this, it can still
be fairly confusing for kernel developers [1], thus use the unstable
`force` option of `--extern` [2] (added in Rust 1.71 [3]) to force the
compiler to resolve `alloc`.
This new unstable feature is only needed meanwhile we use the other
unstable feature, since then we will not need `-Zcrate-attr`.
Cc: stable@vger.kernel.org # v6.6+
Reported-by: Daniel Almeida <daniel.almeida@collabora.com>
Reported-by: Julian Stecklina <julian.stecklina@cyberus-technology.de>
Closes: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/x/near/424096982 [1]
Fixes: 2f7ab1267dc9 ("Kbuild: add Rust support")
Link: https://github.com/rust-lang/rust/issues/111302 [2]
Link: https://github.com/rust-lang/rust/pull/109421 [3]
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://lore.kernel.org/r/20240422090644.525520-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
kernel-doc emits a warning on struct_group_tagged() if you describe your
struct group member:
include/net/libeth/rx.h:69: warning: Excess struct member 'fp' description in 'libeth_fq'
The code:
/**
* struct libeth_fq - structure representing a buffer queue
* @fp: hotpath part of the structure
* @pp: &page_pool for buffer management
[...]
*/
struct libeth_fq {
struct_group_tagged(libeth_fq_fp, fp,
struct page_pool *pp;
[...]
);
When a struct_group_tagged() is encountered, we need to build a
`struct TAG NAME;` from it, so that it will be treated as a valid
embedded struct.
Decouple the regex and do the replacement there. As far as I can see,
this doesn't produce any new warnings on the current mainline tree.
Reported-by: Jakub Kicinski <kuba@kernel.org>
Closes: https://lore.kernel.org/netdev/20240405212513.0d189968@kernel.org
Fixes: 50d7bd38c3aa ("stddef: Introduce struct_group() helper macro")
Signed-off-by: Kees Cook <keescook@chromium.org>
Co-developed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20240411093208.2483580-1-aleksander.lobakin@intel.com
Starting with c23, 'constexpr' is a keyword in C like in C++ and cannot
be used as an identifier:
scripts/unifdef.c:206:25: error: 'constexpr' can only be used in variable declarations
206 | static bool constexpr; /* constant #if expression */
| ^
scripts/unifdef.c:880:13: error: expected identifier or '('
880 | constexpr = false;
| ^
Rename this instance to allow changing to C23 at some point in the future.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-By: Tony Finch <dot@dotat.at>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Currently, kernel modules contain their own set of expoline thunks. In
the case of EXPOLINE_EXTERN, this involves postlinking of precompiled
expoline.o. expoline.o is also necessary for out-of-source tree module
builds.
Now that the kernel modules area is less than 4 GB away from
kernel expoline thunks, make modules use kernel expolines. Also make
EXPOLINE_EXTERN the default if the compiler supports it. This simplifies
build and aligns with the approach adopted by other architectures.
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Switch away from our fork of the `alloc` crate. We remove it altogether
in the next commit.
Signed-off-by: Wedson Almeida Filho <walmeida@microsoft.com>
Link: https://lore.kernel.org/r/20240328013603.206764-4-wedsonaf@gmail.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
The irq_desc::kstat_irqs member is a per-CPU variable of type int, which is
only capable of counting. A snapshot mechanism for interrupt statistics
will be added soon, which requires an additional variable to store the
snapshot.
To facilitate expansion, convert kstat_irqs here to a struct containing
only the count.
Originally-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Bitao Hu <yaoma@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20240411074134.30922-2-yaoma@linux.alibaba.com
Add a script which produces a Flat Image Tree (FIT), a single file
containing the built kernel and associated devicetree files.
Compression defaults to gzip which gives a good balance of size and
performance.
The files compress from about 86MB to 24MB using this approach.
The FIT can be used by bootloaders which support it, such as U-Boot
and Linuxboot. It permits automatic selection of the correct
devicetree, matching the compatible string of the running board with
the closest compatible string in the FIT. There is no need for
filenames or other workarounds.
Add a 'make image.fit' build target for arm64, as well.
The FIT can be examined using 'dumpimage -l'.
This uses the 'dtbs-list' file but processes only .dtb files, ignoring
the overlay .dtbo files.
This features requires pylibfdt (use 'pip install libfdt'). It also
requires compression utilities for the algorithm being used. Supported
compression options are the same as the Image.xxx files. Use
FIT_COMPRESSION to select an algorithm other than gzip.
While FIT supports a ramdisk / initrd, no attempt is made to support
this here, since it must be built separately from the Linux build.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Masahiro Yamada <masahiroy@kernel.org>
Link: https://lore.kernel.org/r/20240329032836.141899-3-sjg@chromium.org
Signed-off-by: Will Deacon <will@kernel.org>
Fedora and openSUSE has started deploying "variable font" [1] format
Noto CJK fonts [2, 3]. "CJK" here stands for "Chinese, Japanese,
and Korean".
Unfortunately, XeTeX/XeLaTeX doesn't understand those fonts for
historical reasons and builds of translations.pdf end up in errors
if such fonts are present on the build host.
To help developers work around the issue, add a script to check the
presence of "variable font" Noto CJK fonts and to emit suggestions.
The script is invoked in the error path of "make pdfdocs" so that the
suggestions are made only when a PDF build actually fails.
The first suggestion is to denylist those "variable font" files by
activating a per-user and command-local fontconfig setting.
For further info and backgrounds, please refer to the header comment
of scripts/check-variable-font.sh newly added in this commit.
Link: [1] https://en.wikipedia.org/wiki/Variable_font
Link: [2] https://fedoraproject.org/wiki/Changes/Noto_CJK_Variable_Fonts
Link: [3] https://build.opensuse.org/request/show/1157217
Reported-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/8734tqsrt7.fsf@meer.lwn.net/
Reported-by: Иван Иванович <relect@bk.ru>
Link: https://lore.kernel.org/linux-doc/1708585803.600323099@f111.i.mail.ru/
Cc: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20240406020416.25096-1-akiyks@gmail.com
The .head.text section carries the startup code that runs with the MMU
off or with a translation of memory that deviates from the ordinary one.
So avoid instrumentation with the stackleak plugin, which already avoids
.init.text and .noinstr.text entirely.
Fixes: 48204aba801f1b51 ("x86/sme: Move early SME kernel encryption handling into .head.text")
Reported-by: kernel test robot <oliver.sang@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202403221630.2692c998-oliver.sang@intel.com
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20240328064256.2358634-2-ardb+git@google.com
Signed-off-by: Kees Cook <keescook@chromium.org>
-----BEGIN PGP SIGNATURE-----
iQFDBAABCAAtFiEEIw+MvkEiF49krdp9F0NaE2wMflgFAmYMH1YPHGNvcmJldEBs
d24ubmV0AAoJEBdDWhNsDH5YgacH/3YREzLrjQz3JMBg1Hm4E+isKJZwfPYBc1I6
jpo5s8mdaJeOevByXYPy1ckiXLtH2OJZaUzTKCyvwS4GBlvw2/ipgdbiR3vY1sXR
XJVUX+88KNWcH0XVDb0aB1tMGo/Wtx6YQ5Zlt+5SQ3aMqwJYzCMIIfjzOq7OJl42
lezW7c6MM+8xhEAfISaaGgtAM/2yuRA41cPs4AxEXH0hT9YPQs7/qy+yN7DDTO1r
E3PVZjW6Cx1/gS0C7DsxTFrh+OjluE54SCQTJO0hi//hqvHBhA1iDEDy/wo9wvLS
G+NYqpTKcb0x9PX3cEH9EsX5ZYUNCrL4qyvMtWEzEy3Z7dmhm8Y=
=6UcE
-----END PGP SIGNATURE-----
Merge tag 'docs-6.9-fixes' of git://git.lwn.net/linux
Pull documentation fixes from Jonathan Corbet:
"Four small documentation fixes"
* tag 'docs-6.9-fixes' of git://git.lwn.net/linux:
docs: zswap: fix shell command format
tracing: Fix documentation on tp_printk cmdline option
docs: Fix bitfield handling in kernel-doc
Documentation: dev-tools: Add link to RV docs
Extend commit 84b4cc8189f2 ("docs: scripts: sphinx-pre-install: Fix
building docs with pyyaml package") and add pyyaml as an optional
package to Mageia, ArchLinux, and Gentoo.
The Python module pyyaml is required to build the docs, but it is only
listed in Documentation/sphinx/requirements.txt and is therefore missing
when Sphinx is installed as a package and not via pip/pypi.
Signed-off-by: Thorsten Blum <thorsten.blum@toblux.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20240323125837.2022-2-thorsten.blum@toblux.com
Rust 1.74.0 introduced (unstable) support for the
`-Zdebuginfo-compression` flag, thus use it.
Note that the releases built by the Rust project (i.e. the ones provided
by rustup) do not enable support for zstd in their bundled LLVM (yet,
at least), thus the Rust compiler will warn, but the build will proceed:
warning: unknown debuginfo compression algorithm zstd - will fall
back to uncompressed debuginfo
Link: https://github.com/rust-lang/rust/issues/120953
Link: https://github.com/rust-lang/rust/pull/115358
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20240217002622.57322-1-ojeda@kernel.org
[ Added note about zstd support in Rust-provided binaries. ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
