pm24.git, branch rust-6.11

docs: rust: quick-start: add section on Linux distributions

2024-07-10T08:29:55Z

Now that we are starting to support several Rust compiler and `bindgen` versions, there is a good chance some Linux distributions work out of the box. Thus, provide some instructions on how to set the toolchain up for a few major Linux distributions. This simplifies the setup users need to build the kernel. In addition, add an introduction to the document so that it is easier to understand its structure and move the LLVM+Rust kernel.org toolchains paragraph there (removing "depending on the Linux version"). We may want to reorganize the document or split it in the future, but I wanted to focus this commit on the new information added about each particular distribution. Finally, remove the `rustup`'s components mention in `changes.rst` since users do not need it if they install the toolchain via the distributions (and anyway it was too detailed for that main document). Cc: Jan Alexander Steffens Cc: Johannes Löthberg Cc: Fabian Grünbichler Cc: Josh Stone Cc: Randy Barlow Cc: Anna (navi) Figueiredo Gomes Cc: Matoro Mahri Cc: Ryan Scheel Cc: figsoda Cc: Jörg Thalheim Cc: Theodore Ni <43ngvg@masqt.com> Cc: Winter Cc: William Brown Cc: Xiaoguang Wang Cc: Andrea Righi Cc: Zixing Liu Cc: Nathan Chancellor Tested-by: Benno Lossin Tested-by: Andreas Hindborg Link: https://lore.kernel.org/r/20240709160615.998336-14-ojeda@kernel.org Signed-off-by: Miguel Ojeda

rust: warn about `bindgen` versions 0.66.0 and 0.66.1

2024-07-10T08:28:52Z

`bindgen` versions 0.66.0 and 0.66.1 panic due to C string literals with NUL characters [1]: panicked at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bindgen-0.66.0/codegen/mod.rs:717:71: called `Result::unwrap()` on an `Err` value: FromBytesWithNulError { kind: InteriorNul(4) } Thus, in preparation for supporting several `bindgen` versions, add a version check to warn the user about it. Since some distributions may have patched it (e.g. Debian did [2]), check if that seems to be the case (after the version check matches), in order to avoid printing a warning in that case. We could make it an error, but 1) it is going to fail anyway later in the build, 2) we would disable `RUST`, which is also painful, 3) someone could have patched it in a way that still makes our extra check fail (however unlikely), 4) the interior NUL may go away in the headers (however unlikely). Thus just warn about it so that users know why it is failing. In addition, add a couple tests for the new cases. Link: https://github.com/rust-lang/rust-bindgen/pull/2567 [1] Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069047 [2] Link: https://lore.kernel.org/r/20240709160615.998336-11-ojeda@kernel.org Signed-off-by: Miguel Ojeda

rust: start supporting several `bindgen` versions

2024-07-10T08:28:52Z

With both the workaround for `bindgen` 0.69.0 and the warning about 0.66.0 and 0.66.1 in place, start supporting several `bindgen` versions, like it was done for the Rust compiler in a previous patch. All other versions, including the latest 0.69.4, build without errors. The `bindgen` project, like Rust, has also agreed to have the kernel in their CI [1] -- thanks! This should help both projects: `bindgen` will be able to detect early issues like those mentioned above, and the kernel will be very likely build with new releases (at least for the basic configuration being tested). Link: https://github.com/rust-lang/rust-bindgen/pull/2851 [1] Tested-by: Benno Lossin Tested-by: Andreas Hindborg Link: https://lore.kernel.org/r/20240709160615.998336-10-ojeda@kernel.org Signed-off-by: Miguel Ojeda

rust: work around `bindgen` 0.69.0 issue

2024-07-10T08:28:52Z

`bindgen` 0.69.0 contains a bug: `--version` does not work without providing a header [1]: error: the following required arguments were not provided:

Usage: bindgen

-- ... Thus, in preparation for supporting several `bindgen` versions, work around the issue by passing a dummy argument. Include a comment so that we can remove the workaround in the future. Link: https://github.com/rust-lang/rust-bindgen/pull/2678 [1] Reviewed-by: Finn Behrens Tested-by: Benno Lossin Tested-by: Andreas Hindborg Link: https://lore.kernel.org/r/20240709160615.998336-9-ojeda@kernel.org Signed-off-by: Miguel Ojeda

rust: avoid assuming a particular `bindgen` build

2024-07-10T08:28:52Z

`bindgen`'s logic to find `libclang` (via `clang-sys`) may change over time, and depends on how it was built (e.g. Linux distributions may decide to build it differently, and we are going to provide documentation on installing it via distributions later in this series). Therefore, clarify that `bindgen` may be built in several ways and simplify the documentation by only mentioning the most prominent environment variable (`LIBCLANG_PATH`) as an example on how to tweak the search of the library at runtime (i.e. when `bindgen` is built as our documentation explains). This also avoids duplicating the documentation, like `bindgen` itself does (i.e. it refers to `clang-sys`). Similarly, replace the test we had for this (which used the real program) with a mocked one, to avoid depending on the particular build as well. Tested-by: Benno Lossin Tested-by: Andreas Hindborg Link: https://lore.kernel.org/r/20240709160615.998336-8-ojeda@kernel.org Signed-off-by: Miguel Ojeda

rust: start supporting several compiler versions

2024-07-10T08:28:52Z

It is time to start supporting several Rust compiler versions and thus establish a minimum Rust version. We may still want to upgrade the minimum sometimes in the beginning since there may be important features coming into the language that improve how we write code (e.g. field projections), which may or may not make sense to support conditionally. We will start with a window of two stable releases, and widen it over time. Thus this patch does not move the current minimum (1.78.0), but instead adds support for the recently released 1.79.0. This should already be enough for kernel developers in distributions that provide recent Rust compiler versions routinely, such as Arch Linux, Debian Unstable (outside the freeze period), Fedora Linux, Gentoo Linux (especially the testing channel), Nix (unstable) and openSUSE Tumbleweed. See the documentation patch about it later in this series. In addition, Rust for Linux is now being built-tested in Rust's pre-merge CI [1]. That is, every change that is attempting to land into the Rust compiler is tested against the kernel, and it is merged only if it passes -- thanks to the Rust project for that! Thus, with the pre-merge CI in place, both projects hope to avoid unintentional changes to Rust that break the kernel. This means that, in general, apart from intentional changes on their side (that we will need to workaround conditionally on our side), the upcoming Rust compiler versions should generally work. For instance, currently, the beta (1.80.0) and nightly (1.81.0) branches work as well. Of course, the Rust for Linux CI job in the Rust toolchain may still need to be temporarily disabled for different reasons, but the intention is to help bring Rust for Linux into stable Rust. Link: https://github.com/rust-lang/rust/pull/125209 [1] Reviewed-by: Finn Behrens Tested-by: Benno Lossin Tested-by: Andreas Hindborg Link: https://lore.kernel.org/r/20240709160615.998336-7-ojeda@kernel.org Signed-off-by: Miguel Ojeda

rust: simplify Clippy warning flags set

2024-07-10T08:28:52Z

All Clippy lint groups that we enable, except `correctness`, have a default `warn` level, thus they may be removed now that we relaxed all lints to `warn`. Moreover, Clippy provides an `all` lint group that covers the groups we enable by default. Thus just use `all` instead -- the only change is that, if Clippy introduces a new lint group or splits an existing one, we will cover that one automatically. In addition, `let_unit_value` is in `style` since Rust 1.62.0, thus it does not need to be enabled manually. Reviewed-by: Finn Behrens Tested-by: Benno Lossin Tested-by: Andreas Hindborg Link: https://lore.kernel.org/r/20240709160615.998336-6-ojeda@kernel.org Signed-off-by: Miguel Ojeda

rust: relax most deny-level lints to warnings

2024-07-10T08:28:51Z

Since we are starting to support several Rust toolchains, lints (including Clippy ones) now may behave differently and lint groups may include new lints. Therefore, to maximize the chances a given version works, relax some deny-level lints to warnings. It may also make our lives a bit easier while developing new code or refactoring. To be clear, the requirements for in-tree code are still the same, since Rust code still needs to be warning-free (patches should be clean under `WERROR=y`) and the set of lints is not changed. `unsafe_op_in_unsafe_fn` is left unmodified, i.e. as an error, since it is becoming the default in the language (warn-by-default in Rust 2024 [1] and ideally an error later on) and thus it should also be very well tested. In addition, it is simple enough that it should not have false positives (unlike e.g. `rust_2018_idioms`'s `explicit_outlives_requirements`). `non_ascii_idents` is left unmodified as well, i.e. as an error, since it is unlikely one gains any productivity during development if it were a warning (in fact, it may be worse, since it is likely one made a typo). In addition, it should not have false positives. Finally, put the two `-D` ones at the top and take the chance to do one per line. Link: https://github.com/rust-lang/rust/pull/112038 [1] Reviewed-by: Finn Behrens Tested-by: Benno Lossin Tested-by: Andreas Hindborg Link: https://lore.kernel.org/r/20240709160615.998336-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda

rust: allow `dead_code` for never constructed bindings

2024-07-10T08:28:51Z

Starting with the upcoming Rust 1.80.0 (since upstream commit 35130d7233e9 ("Detect pub structs never constructed and unused associated constants in traits")), the `dead_code` pass detects more cases, which triggers in the `bindings` crate: warning: struct `boot_params` is never constructed --> rust/bindings/bindings_generated.rs:10684:12 | 10684 | pub struct boot_params { | ^^^^^^^^^^^ | = note: `#[warn(dead_code)]` on by default As well as in the `uapi` one: warning: struct `boot_params` is never constructed --> rust/uapi/uapi_generated.rs:10392:12 | 10392 | pub struct boot_params { | ^^^^^^^^^^^ | = note: `#[warn(dead_code)]` on by default These are all expected, since we do not use all the structs in the bindings that `bindgen` generates from the C headers. Therefore, allow them. Reviewed-by: Björn Roy Baron Reviewed-by: Finn Behrens Tested-by: Benno Lossin Tested-by: Andreas Hindborg Link: https://lore.kernel.org/r/20240709160615.998336-4-ojeda@kernel.org Signed-off-by: Miguel Ojeda

rust: init: simplify from `map_err` to `inspect_err`

2024-07-10T08:28:51Z

A new complexity lint, `manual_inspect` [1], has been introduced in the upcoming Rust 1.81 (currently in nightly), which checks for uses of `map*` which return the original item: error: --> rust/kernel/init.rs:846:23 | 846 | (self.1)(val).map_err(|e| { | ^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#manual_inspect = note: `-D clippy::manual-inspect` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::manual_inspect)]` help: try | 846 ~ (self.1)(val).inspect_err(|e| { 847 | // SAFETY: `slot` was initialized above. 848 ~ unsafe { core::ptr::drop_in_place(slot) }; | Thus clean them up. Link: https://rust-lang.github.io/rust-clippy/master/index.html#/manual_inspect [1] Tested-by: Benno Lossin Tested-by: Andreas Hindborg Link: https://lore.kernel.org/r/20240709160615.998336-3-ojeda@kernel.org Signed-off-by: Miguel Ojeda