[PATCH 00/13] Support several Rust toolchain versions

[PATCH 00/13] Support several Rust toolchain versions

[Miguel Ojeda]

Hi all,

It is time to start supporting several Rust toolchain versions and thus
establish a minimum Rust compiler and `bindgen` version.

For the Rust compiler, we will start with a window of two stable
releases, and widen it over time. This series keeps the minimum where
it is (1.78.0), but 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. A documentation adds the instructions for each of them.

In addition, Rust for Linux is now being built-tested in Rust's
pre-merge CI. 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.

Similarly, we kept the minimum as it is for `bindgen`. `bindgen` is also
adding the kernel to its CI -- thanks!

Cheers,
Miguel


Miguel Ojeda (13):
  rust: macros: indent list item in `paste!`'s docs
  rust: init: simplify from `map_err` to `inspect_err`
  rust: allow `dead_code` for never constructed bindings
  rust: relax most deny-level lints to warnings
  rust: simplify Clippy warning flags set
  rust: start supporting several compiler versions
  rust: warn about `bindgen` versions 0.66.0 and 0.66.1
  rust: work around `bindgen` 0.69.0 issue
  rust: avoid assuming a particular `bindgen` build
  rust: start supporting several `bindgen` versions
  kbuild: rust: add `rustc-version` support
  rust: support the new `-Zub-checks` flag
  docs: rust: quick-start: add section on Linux distributions

 Documentation/process/changes.rst  |   9 +--
 Documentation/rust/quick-start.rst | 118 +++++++++++++++++++++++------
 Makefile                           |  29 +++----
 init/Kconfig                       |  11 ++-
 lib/Kconfig.debug                  |  18 +++++
 rust/Makefile                      |   4 +-
 rust/bindings/lib.rs               |   1 +
 rust/kernel/init.rs                |  12 +--
 rust/macros/lib.rs                 |   2 +-
 rust/uapi/lib.rs                   |   1 +
 scripts/Kconfig.include            |   6 ++
 scripts/Makefile.compiler          |   4 +
 scripts/rust_is_available.sh       |  20 ++---
 scripts/rust_is_available_test.py  |  40 +++++-----
 scripts/rustc-version.sh           |  52 +++++++++++++
 15 files changed, 238 insertions(+), 89 deletions(-)
 create mode 100755 scripts/rustc-version.sh


base-commit: f2661062f16b2de5d7b6a5c42a9a5c96326b8454
-- 
2.45.2

[PATCH 01/13] rust: macros: indent list item in `paste!`'s docs

[Miguel Ojeda]

A new style lint, `doc_lazy_continuation` [1], has been introduced in the
upcoming Rust 1.80 (currently in beta), which detects missing indentation
in code documentation.

We have one such case:

    error: doc list item missing indentation
    --> rust/macros/lib.rs:315:5
        |
    315 | /// default the span of the `[< >]` group is used.
        |     ^
        |
        = help: if this is supposed to be its own paragraph, add a blank line
        = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#doc_lazy_continuation
        = note: `-D clippy::doc-lazy-continuation` implied by `-D clippy::style`
        = help: to override `-D clippy::style` add `#[allow(clippy::doc_lazy_continuation)]`
    help: indent this line
        |
    315 | ///   default the span of the `[< >]` group is used.
        |     ++

While the rendering of the docs by `rustdoc` is not affected, we apply
this kind of indentation elsewhere since it looks better.

Thus clean it up.

Link: https://rust-lang.github.io/rust-clippy/master/index.html#/doc_lazy_continuation [1]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 rust/macros/lib.rs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rust/macros/lib.rs b/rust/macros/lib.rs
index 520eae5fd792..05d976b3c09a 100644
--- a/rust/macros/lib.rs
+++ b/rust/macros/lib.rs
@@ -312,7 +312,7 @@ pub fn pinned_drop(args: TokenStream, input: TokenStream) -> TokenStream {
 ///
 /// Currently supported modifiers are:
 /// * `span`: change the span of concatenated identifier to the span of the specified token. By
-/// default the span of the `[< >]` group is used.
+///   default the span of the `[< >]` group is used.
 /// * `lower`: change the identifier to lower case.
 /// * `upper`: change the identifier to upper case.
 ///
-- 
2.45.2

Re: [PATCH 01/13] rust: macros: indent list item in `paste!`'s docs

[Björn Roy Baron]

On Monday, July 1st, 2024 at 20:36, Miguel Ojeda <ojeda@kernel.org> wrote:

> A new style lint, `doc_lazy_continuation` [1], has been introduced in the
> upcoming Rust 1.80 (currently in beta), which detects missing indentation
> in code documentation.
> 
> We have one such case:
> 
>     error: doc list item missing indentation
>     --> rust/macros/lib.rs:315:5
>         |
>     315 | /// default the span of the `[< >]` group is used.
>         |     ^
>         |
>         = help: if this is supposed to be its own paragraph, add a blank line
>         = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#doc_lazy_continuation
>         = note: `-D clippy::doc-lazy-continuation` implied by `-D clippy::style`
>         = help: to override `-D clippy::style` add `#[allow(clippy::doc_lazy_continuation)]`
>     help: indent this line
>         |
>     315 | ///   default the span of the `[< >]` group is used.
>         |     ++
> 
> While the rendering of the docs by `rustdoc` is not affected, we apply
> this kind of indentation elsewhere since it looks better.
> 
> Thus clean it up.
> 
> Link: https://rust-lang.github.io/rust-clippy/master/index.html#/doc_lazy_continuation [1]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Reviewed-by: Björn Roy Baron <bjorn3_gh@protonmail.com>

> ---
>  rust/macros/lib.rs | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/rust/macros/lib.rs b/rust/macros/lib.rs
> index 520eae5fd792..05d976b3c09a 100644
> --- a/rust/macros/lib.rs
> +++ b/rust/macros/lib.rs
> @@ -312,7 +312,7 @@ pub fn pinned_drop(args: TokenStream, input: TokenStream) -> TokenStream {
>  ///
>  /// Currently supported modifiers are:
>  /// * `span`: change the span of concatenated identifier to the span of the specified token. By
> -/// default the span of the `[< >]` group is used.
> +///   default the span of the `[< >]` group is used.
>  /// * `lower`: change the identifier to lower case.
>  /// * `upper`: change the identifier to upper case.
>  ///
> --
> 2.45.2

Re: [PATCH 01/13] rust: macros: indent list item in `paste!`'s docs

[Finn Behrens]

On 1 Jul 2024, at 20:36, Miguel Ojeda wrote:

> A new style lint, `doc_lazy_continuation` [1], has been introduced in the
> upcoming Rust 1.80 (currently in beta), which detects missing indentation
> in code documentation.
>
> We have one such case:
>
>     error: doc list item missing indentation
>     --> rust/macros/lib.rs:315:5
>         |
>     315 | /// default the span of the `[< >]` group is used.
>         |     ^
>         |
>         = help: if this is supposed to be its own paragraph, add a blank line
>         = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#doc_lazy_continuation
>         = note: `-D clippy::doc-lazy-continuation` implied by `-D clippy::style`
>         = help: to override `-D clippy::style` add `#[allow(clippy::doc_lazy_continuation)]`
>     help: indent this line
>         |
>     315 | ///   default the span of the `[< >]` group is used.
>         |     ++
>
> While the rendering of the docs by `rustdoc` is not affected, we apply
> this kind of indentation elsewhere since it looks better.
>
> Thus clean it up.
>
> Link: https://rust-lang.github.io/rust-clippy/master/index.html#/doc_lazy_continuation [1]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Reviewed-by: Finn Behrens <me@kloenk.dev>

> ---
>  rust/macros/lib.rs | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/rust/macros/lib.rs b/rust/macros/lib.rs
> index 520eae5fd792..05d976b3c09a 100644
> --- a/rust/macros/lib.rs
> +++ b/rust/macros/lib.rs
> @@ -312,7 +312,7 @@ pub fn pinned_drop(args: TokenStream, input: TokenStream) -> TokenStream {
>  ///
>  /// Currently supported modifiers are:
>  /// * `span`: change the span of concatenated identifier to the span of the specified token. By
> -/// default the span of the `[< >]` group is used.
> +///   default the span of the `[< >]` group is used.
>  /// * `lower`: change the identifier to lower case.
>  /// * `upper`: change the identifier to upper case.
>  ///
> -- 
> 2.45.2

[PATCH 02/13] rust: init: simplify from `map_err` to `inspect_err`

[Miguel Ojeda]

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]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 rust/kernel/init.rs | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/rust/kernel/init.rs b/rust/kernel/init.rs
index 68605b633e73..07bacf134c19 100644
--- a/rust/kernel/init.rs
+++ b/rust/kernel/init.rs
@@ -843,11 +843,9 @@ unsafe fn __pinned_init(self, slot: *mut T) -> Result<(), E> {
         let val = unsafe { &mut *slot };
         // SAFETY: `slot` is considered pinned.
         let val = unsafe { Pin::new_unchecked(val) };
-        (self.1)(val).map_err(|e| {
+        (self.1)(val).inspect_err(|_|
             // SAFETY: `slot` was initialized above.
-            unsafe { core::ptr::drop_in_place(slot) };
-            e
-        })
+            unsafe { core::ptr::drop_in_place(slot) })
     }
 }
 
@@ -941,11 +939,9 @@ unsafe fn __init(self, slot: *mut T) -> Result<(), E> {
         // SAFETY: All requirements fulfilled since this function is `__init`.
         unsafe { self.0.__pinned_init(slot)? };
         // SAFETY: The above call initialized `slot` and we still have unique access.
-        (self.1)(unsafe { &mut *slot }).map_err(|e| {
+        (self.1)(unsafe { &mut *slot }).inspect_err(|_|
             // SAFETY: `slot` was initialized above.
-            unsafe { core::ptr::drop_in_place(slot) };
-            e
-        })
+            unsafe { core::ptr::drop_in_place(slot) })
     }
 }
 
-- 
2.45.2

Re: [PATCH 02/13] rust: init: simplify from `map_err` to `inspect_err`

[Björn Roy Baron]

On Monday, July 1st, 2024 at 20:36, Miguel Ojeda <ojeda@kernel.org> wrote:

> 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]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
>  rust/kernel/init.rs | 12 ++++--------
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/rust/kernel/init.rs b/rust/kernel/init.rs
> index 68605b633e73..07bacf134c19 100644
> --- a/rust/kernel/init.rs
> +++ b/rust/kernel/init.rs
> @@ -843,11 +843,9 @@ unsafe fn __pinned_init(self, slot: *mut T) -> Result<(), E> {
>          let val = unsafe { &mut *slot };
>          // SAFETY: `slot` is considered pinned.
>          let val = unsafe { Pin::new_unchecked(val) };
> -        (self.1)(val).map_err(|e| {
> +        (self.1)(val).inspect_err(|_|
>              // SAFETY: `slot` was initialized above.
> -            unsafe { core::ptr::drop_in_place(slot) };
> -            e
> -        })
> +            unsafe { core::ptr::drop_in_place(slot) })

The formatting here is a bit weird. I would have expected the ) ending the inspect_err call to be placed on a new line given that the unsafe block isn't placed on the same line as the start of the inspect_err call either. This seems to be a case where rustfmt mostly gives up on formatting. If I deindent the comment and unsafe block rustfmt will keep it that way and if I add a trailing space to the inspect_err line it will keep it and emit an error that it left behind trailing whitespace. Maybe add a block around the comment and unsafe block to make rustfmt work again?

>      }
>  }
> 
> @@ -941,11 +939,9 @@ unsafe fn __init(self, slot: *mut T) -> Result<(), E> {
>          // SAFETY: All requirements fulfilled since this function is `__init`.
>          unsafe { self.0.__pinned_init(slot)? };
>          // SAFETY: The above call initialized `slot` and we still have unique access.
> -        (self.1)(unsafe { &mut *slot }).map_err(|e| {
> +        (self.1)(unsafe { &mut *slot }).inspect_err(|_|
>              // SAFETY: `slot` was initialized above.
> -            unsafe { core::ptr::drop_in_place(slot) };
> -            e
> -        })
> +            unsafe { core::ptr::drop_in_place(slot) })
>      }
>  }
> 
> --
> 2.45.2

Re: [PATCH 02/13] rust: init: simplify from `map_err` to `inspect_err`

[Miguel Ojeda]

On Mon, Jul 1, 2024 at 10:05 PM Björn Roy Baron
<bjorn3_gh@protonmail.com> wrote:
>
> The formatting here is a bit weird. I would have expected the ) ending the inspect_err call to be placed on a new line given that the unsafe block isn't placed on the same line as the start of the inspect_err call either. This seems to be a case where rustfmt mostly gives up on formatting. If I deindent the comment and unsafe block rustfmt will keep it that way and if I add a trailing space to the inspect_err line it will keep it and emit an error that it left behind trailing whitespace. Maybe add a block around the comment and unsafe block to make rustfmt work again?

Benno: any preference here? Or even open coding it.

Thanks Björn!

Cheers,
Miguel

Re: [PATCH 02/13] rust: init: simplify from `map_err` to `inspect_err`

[Benno Lossin]

On 01.07.24 23:58, Miguel Ojeda wrote:
> On Mon, Jul 1, 2024 at 10:05 PM Björn Roy Baron
> <bjorn3_gh@protonmail.com> wrote:
>>
>> The formatting here is a bit weird. I would have expected the ) ending the inspect_err call to be placed on a new line given that the unsafe block isn't placed on the same line as the start of the inspect_err call either. This seems to be a case where rustfmt mostly gives up on formatting. If I deindent the comment and unsafe block rustfmt will keep it that way and if I add a trailing space to the inspect_err line it will keep it and emit an error that it left behind trailing whitespace. Maybe add a block around the comment and unsafe block to make rustfmt work again?
> 
> Benno: any preference here? Or even open coding it.

I would put the comment outside of the closure:

    let val = unsafe { &mut *slot };
    // SAFETY: `slot` is considered pinned.
    let val = unsafe { Pin::new_unchecked(val) };
    // SAFETY: `slot` was initialized above.
    (self.1)(val).inspect_err(|_| unsafe { core::ptr::drop_in_place(slot) })

---
Cheers,
Benno

Re: [PATCH 02/13] rust: init: simplify from `map_err` to `inspect_err`

[Alice Ryhl]

On Mon, Jul 1, 2024 at 11:58 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Mon, Jul 1, 2024 at 10:05 PM Björn Roy Baron
> <bjorn3_gh@protonmail.com> wrote:
> >
> > The formatting here is a bit weird. I would have expected the ) ending the inspect_err call to be placed on a new line given that the unsafe block isn't placed on the same line as the start of the inspect_err call either. This seems to be a case where rustfmt mostly gives up on formatting. If I deindent the comment and unsafe block rustfmt will keep it that way and if I add a trailing space to the inspect_err line it will keep it and emit an error that it left behind trailing whitespace. Maybe add a block around the comment and unsafe block to make rustfmt work again?
>
> Benno: any preference here? Or even open coding it.

I would open code it with an `if res.is_err() { drop }`. Using inspect
for a side effect other than printing seems weird to me.

Alice

[PATCH 03/13] rust: allow `dead_code` for never constructed bindings

[Miguel Ojeda]

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.

Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 rust/bindings/lib.rs | 1 +
 rust/uapi/lib.rs     | 1 +
 2 files changed, 2 insertions(+)

diff --git a/rust/bindings/lib.rs b/rust/bindings/lib.rs
index 40ddaee50d8b..93a1a3fc97bc 100644
--- a/rust/bindings/lib.rs
+++ b/rust/bindings/lib.rs
@@ -24,6 +24,7 @@
     unsafe_op_in_unsafe_fn
 )]
 
+#[allow(dead_code)]
 mod bindings_raw {
     // Use glob import here to expose all helpers.
     // Symbols defined within the module will take precedence to the glob import.
diff --git a/rust/uapi/lib.rs b/rust/uapi/lib.rs
index 0caad902ba40..80a00260e3e7 100644
--- a/rust/uapi/lib.rs
+++ b/rust/uapi/lib.rs
@@ -14,6 +14,7 @@
 #![cfg_attr(test, allow(unsafe_op_in_unsafe_fn))]
 #![allow(
     clippy::all,
+    dead_code,
     missing_docs,
     non_camel_case_types,
     non_upper_case_globals,
-- 
2.45.2

Re: [PATCH 03/13] rust: allow `dead_code` for never constructed bindings

[Björn Roy Baron]

On Monday, July 1st, 2024 at 20:36, Miguel Ojeda <ojeda@kernel.org> wrote:

> 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.
> 
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Reviewed-by: Björn Roy Baron <bjorn3_gh@protonmail.com>

> ---
>  rust/bindings/lib.rs | 1 +
>  rust/uapi/lib.rs     | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/rust/bindings/lib.rs b/rust/bindings/lib.rs
> index 40ddaee50d8b..93a1a3fc97bc 100644
> --- a/rust/bindings/lib.rs
> +++ b/rust/bindings/lib.rs
> @@ -24,6 +24,7 @@
>      unsafe_op_in_unsafe_fn
>  )]
>  
> +#[allow(dead_code)]
>  mod bindings_raw {
>      // Use glob import here to expose all helpers.
>      // Symbols defined within the module will take precedence to the glob import.
> diff --git a/rust/uapi/lib.rs b/rust/uapi/lib.rs
> index 0caad902ba40..80a00260e3e7 100644
> --- a/rust/uapi/lib.rs
> +++ b/rust/uapi/lib.rs
> @@ -14,6 +14,7 @@
>  #![cfg_attr(test, allow(unsafe_op_in_unsafe_fn))]
>  #![allow(
>      clippy::all,
> +    dead_code,
>      missing_docs,
>      non_camel_case_types,
>      non_upper_case_globals,
> -- 
> 2.45.2

Re: [PATCH 03/13] rust: allow `dead_code` for never constructed bindings

[Finn Behrens]

On 1 Jul 2024, at 20:36, Miguel Ojeda wrote:

> 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.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Reviewed-by: Finn Behrens <me@kloenk.dev>

> ---
>  rust/bindings/lib.rs | 1 +
>  rust/uapi/lib.rs     | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/rust/bindings/lib.rs b/rust/bindings/lib.rs
> index 40ddaee50d8b..93a1a3fc97bc 100644
> --- a/rust/bindings/lib.rs
> +++ b/rust/bindings/lib.rs
> @@ -24,6 +24,7 @@
>      unsafe_op_in_unsafe_fn
>  )]
>
> +#[allow(dead_code)]
>  mod bindings_raw {
>      // Use glob import here to expose all helpers.
>      // Symbols defined within the module will take precedence to the glob import.
> diff --git a/rust/uapi/lib.rs b/rust/uapi/lib.rs
> index 0caad902ba40..80a00260e3e7 100644
> --- a/rust/uapi/lib.rs
> +++ b/rust/uapi/lib.rs
> @@ -14,6 +14,7 @@
>  #![cfg_attr(test, allow(unsafe_op_in_unsafe_fn))]
>  #![allow(
>      clippy::all,
> +    dead_code,
>      missing_docs,
>      non_camel_case_types,
>      non_upper_case_globals,
> -- 
> 2.45.2

[PATCH 04/13] rust: relax most deny-level lints to warnings

[Miguel Ojeda]

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
1) it is simple enough that it should not have false positives (unlike
e.g. `rust_2018_idioms`'s `explicit_outlives_requirements`) and 2) 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.

Link: https://github.com/rust-lang/rust/pull/112038 [1]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 Makefile      | 22 +++++++++++-----------
 rust/Makefile |  4 ++--
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/Makefile b/Makefile
index 4d36f943b3b1..056176a55d63 100644
--- a/Makefile
+++ b/Makefile
@@ -461,17 +461,17 @@ KBUILD_USERLDFLAGS := $(USERLDFLAGS)
 # host programs.
 export rust_common_flags := --edition=2021 \
 			    -Zbinary_dep_depinfo=y \
-			    -Dunsafe_op_in_unsafe_fn -Drust_2018_idioms \
-			    -Dunreachable_pub -Dnon_ascii_idents \
+			    -Dunsafe_op_in_unsafe_fn -Wrust_2018_idioms \
+			    -Wunreachable_pub -Wnon_ascii_idents \
 			    -Wmissing_docs \
-			    -Drustdoc::missing_crate_level_docs \
-			    -Dclippy::correctness -Dclippy::style \
-			    -Dclippy::suspicious -Dclippy::complexity \
-			    -Dclippy::perf \
-			    -Dclippy::let_unit_value -Dclippy::mut_mut \
-			    -Dclippy::needless_bitwise_bool \
-			    -Dclippy::needless_continue \
-			    -Dclippy::no_mangle_with_rust_abi \
+			    -Wrustdoc::missing_crate_level_docs \
+			    -Wclippy::correctness -Wclippy::style \
+			    -Wclippy::suspicious -Wclippy::complexity \
+			    -Wclippy::perf \
+			    -Wclippy::let_unit_value -Wclippy::mut_mut \
+			    -Wclippy::needless_bitwise_bool \
+			    -Wclippy::needless_continue \
+			    -Wclippy::no_mangle_with_rust_abi \
 			    -Wclippy::dbg_macro
 
 KBUILD_HOSTCFLAGS   := $(KBUILD_USERHOSTCFLAGS) $(HOST_LFS_CFLAGS) $(HOSTCFLAGS)
@@ -573,7 +573,7 @@ KBUILD_RUSTFLAGS := $(rust_common_flags) \
 		    -Csymbol-mangling-version=v0 \
 		    -Crelocation-model=static \
 		    -Zfunction-sections=n \
-		    -Dclippy::float_arithmetic
+		    -Wclippy::float_arithmetic
 
 KBUILD_AFLAGS_KERNEL :=
 KBUILD_CFLAGS_KERNEL :=
diff --git a/rust/Makefile b/rust/Makefile
index f70d5e244fee..4c03e53d3084 100644
--- a/rust/Makefile
+++ b/rust/Makefile
@@ -421,7 +421,7 @@ ifneq ($(or $(CONFIG_ARM64),$(and $(CONFIG_RISCV),$(CONFIG_64BIT))),)
 endif
 
 $(obj)/core.o: private skip_clippy = 1
-$(obj)/core.o: private skip_flags = -Dunreachable_pub
+$(obj)/core.o: private skip_flags = -Wunreachable_pub
 $(obj)/core.o: private rustc_objcopy = $(foreach sym,$(redirect-intrinsics),--redefine-sym $(sym)=__rust$(sym))
 $(obj)/core.o: private rustc_target_flags = $(core-cfgs)
 $(obj)/core.o: $(RUST_LIB_SRC)/core/src/lib.rs FORCE
@@ -435,7 +435,7 @@ $(obj)/compiler_builtins.o: $(src)/compiler_builtins.rs $(obj)/core.o FORCE
 	+$(call if_changed_dep,rustc_library)
 
 $(obj)/alloc.o: private skip_clippy = 1
-$(obj)/alloc.o: private skip_flags = -Dunreachable_pub
+$(obj)/alloc.o: private skip_flags = -Wunreachable_pub
 $(obj)/alloc.o: private rustc_target_flags = $(alloc-cfgs)
 $(obj)/alloc.o: $(RUST_LIB_SRC)/alloc/src/lib.rs $(obj)/compiler_builtins.o FORCE
 	+$(call if_changed_dep,rustc_library)
-- 
2.45.2

Re: [PATCH 04/13] rust: relax most deny-level lints to warnings

[Björn Roy Baron]

On Monday, July 1st, 2024 at 20:36, Miguel Ojeda <ojeda@kernel.org> wrote:

> 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
> 1) it is simple enough that it should not have false positives (unlike
> e.g. `rust_2018_idioms`'s `explicit_outlives_requirements`) and 2) 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.
> 
> Link: https://github.com/rust-lang/rust/pull/112038 [1]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> ---
>  Makefile      | 22 +++++++++++-----------
>  rust/Makefile |  4 ++--
>  2 files changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 4d36f943b3b1..056176a55d63 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -461,17 +461,17 @@ KBUILD_USERLDFLAGS := $(USERLDFLAGS)
>  # host programs.
>  export rust_common_flags := --edition=2021 \
>  			    -Zbinary_dep_depinfo=y \
> -			    -Dunsafe_op_in_unsafe_fn -Drust_2018_idioms \
> -			    -Dunreachable_pub -Dnon_ascii_idents \
> +			    -Dunsafe_op_in_unsafe_fn -Wrust_2018_idioms \
> +			    -Wunreachable_pub -Wnon_ascii_idents \

Maybe also keep non_ascii_idents as error? It shouldn't have any false positives.

>  			    -Wmissing_docs \
> -			    -Drustdoc::missing_crate_level_docs \
> -			    -Dclippy::correctness -Dclippy::style \
> -			    -Dclippy::suspicious -Dclippy::complexity \
> -			    -Dclippy::perf \
> -			    -Dclippy::let_unit_value -Dclippy::mut_mut \
> -			    -Dclippy::needless_bitwise_bool \
> -			    -Dclippy::needless_continue \
> -			    -Dclippy::no_mangle_with_rust_abi \
> +			    -Wrustdoc::missing_crate_level_docs \
> +			    -Wclippy::correctness -Wclippy::style \
> +			    -Wclippy::suspicious -Wclippy::complexity \
> +			    -Wclippy::perf \
> +			    -Wclippy::let_unit_value -Wclippy::mut_mut \
> +			    -Wclippy::needless_bitwise_bool \
> +			    -Wclippy::needless_continue \
> +			    -Wclippy::no_mangle_with_rust_abi \
>  			    -Wclippy::dbg_macro
> 
>  KBUILD_HOSTCFLAGS   := $(KBUILD_USERHOSTCFLAGS) $(HOST_LFS_CFLAGS) $(HOSTCFLAGS)
> @@ -573,7 +573,7 @@ KBUILD_RUSTFLAGS := $(rust_common_flags) \
>  		    -Csymbol-mangling-version=v0 \
>  		    -Crelocation-model=static \
>  		    -Zfunction-sections=n \
> -		    -Dclippy::float_arithmetic
> +		    -Wclippy::float_arithmetic
> 
>  KBUILD_AFLAGS_KERNEL :=
>  KBUILD_CFLAGS_KERNEL :=
> diff --git a/rust/Makefile b/rust/Makefile
> index f70d5e244fee..4c03e53d3084 100644
> --- a/rust/Makefile
> +++ b/rust/Makefile
> @@ -421,7 +421,7 @@ ifneq ($(or $(CONFIG_ARM64),$(and $(CONFIG_RISCV),$(CONFIG_64BIT))),)
>  endif
> 
>  $(obj)/core.o: private skip_clippy = 1
> -$(obj)/core.o: private skip_flags = -Dunreachable_pub
> +$(obj)/core.o: private skip_flags = -Wunreachable_pub
>  $(obj)/core.o: private rustc_objcopy = $(foreach sym,$(redirect-intrinsics),--redefine-sym $(sym)=__rust$(sym))
>  $(obj)/core.o: private rustc_target_flags = $(core-cfgs)
>  $(obj)/core.o: $(RUST_LIB_SRC)/core/src/lib.rs FORCE
> @@ -435,7 +435,7 @@ $(obj)/compiler_builtins.o: $(src)/compiler_builtins.rs $(obj)/core.o FORCE
>  	+$(call if_changed_dep,rustc_library)
> 
>  $(obj)/alloc.o: private skip_clippy = 1
> -$(obj)/alloc.o: private skip_flags = -Dunreachable_pub
> +$(obj)/alloc.o: private skip_flags = -Wunreachable_pub
>  $(obj)/alloc.o: private rustc_target_flags = $(alloc-cfgs)
>  $(obj)/alloc.o: $(RUST_LIB_SRC)/alloc/src/lib.rs $(obj)/compiler_builtins.o FORCE
>  	+$(call if_changed_dep,rustc_library)
> --
> 2.45.2

Cheers,
Bjorn

Re: [PATCH 04/13] rust: relax most deny-level lints to warnings

[Miguel Ojeda]

On Mon, Jul 1, 2024 at 9:49 PM Björn Roy Baron <bjorn3_gh@protonmail.com> wrote:
>
> Maybe also keep non_ascii_idents as error? It shouldn't have any false positives.

I was on the fence for that one too. It is also unlikely that having
it as `-W` helps "productivity", i.e. I don't expect anybody to be
helped by being able to type non-ASCII identifiers during development.
:)

Happy either way.

Thanks for the quick review, too!

Cheers,
Miguel

Re: [PATCH 04/13] rust: relax most deny-level lints to warnings

[Finn Behrens]

On 1 Jul 2024, at 20:36, Miguel Ojeda wrote:

> 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
> 1) it is simple enough that it should not have false positives (unlike
> e.g. `rust_2018_idioms`'s `explicit_outlives_requirements`) and 2) 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.
>
> Link: https://github.com/rust-lang/rust/pull/112038 [1]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Also in favour of disallowing non ASCII idents. Either way

Reviewed-by: Finn Behrens <me@kloenk.dev>

> ---
>  Makefile      | 22 +++++++++++-----------
>  rust/Makefile |  4 ++--
>  2 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 4d36f943b3b1..056176a55d63 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -461,17 +461,17 @@ KBUILD_USERLDFLAGS := $(USERLDFLAGS)
>  # host programs.
>  export rust_common_flags := --edition=2021 \
>  			    -Zbinary_dep_depinfo=y \
> -			    -Dunsafe_op_in_unsafe_fn -Drust_2018_idioms \
> -			    -Dunreachable_pub -Dnon_ascii_idents \
> +			    -Dunsafe_op_in_unsafe_fn -Wrust_2018_idioms \
> +			    -Wunreachable_pub -Wnon_ascii_idents \
>  			    -Wmissing_docs \
> -			    -Drustdoc::missing_crate_level_docs \
> -			    -Dclippy::correctness -Dclippy::style \
> -			    -Dclippy::suspicious -Dclippy::complexity \
> -			    -Dclippy::perf \
> -			    -Dclippy::let_unit_value -Dclippy::mut_mut \
> -			    -Dclippy::needless_bitwise_bool \
> -			    -Dclippy::needless_continue \
> -			    -Dclippy::no_mangle_with_rust_abi \
> +			    -Wrustdoc::missing_crate_level_docs \
> +			    -Wclippy::correctness -Wclippy::style \
> +			    -Wclippy::suspicious -Wclippy::complexity \
> +			    -Wclippy::perf \
> +			    -Wclippy::let_unit_value -Wclippy::mut_mut \
> +			    -Wclippy::needless_bitwise_bool \
> +			    -Wclippy::needless_continue \
> +			    -Wclippy::no_mangle_with_rust_abi \
>  			    -Wclippy::dbg_macro
>
>  KBUILD_HOSTCFLAGS   := $(KBUILD_USERHOSTCFLAGS) $(HOST_LFS_CFLAGS) $(HOSTCFLAGS)
> @@ -573,7 +573,7 @@ KBUILD_RUSTFLAGS := $(rust_common_flags) \
>  		    -Csymbol-mangling-version=v0 \
>  		    -Crelocation-model=static \
>  		    -Zfunction-sections=n \
> -		    -Dclippy::float_arithmetic
> +		    -Wclippy::float_arithmetic
>
>  KBUILD_AFLAGS_KERNEL :=
>  KBUILD_CFLAGS_KERNEL :=
> diff --git a/rust/Makefile b/rust/Makefile
> index f70d5e244fee..4c03e53d3084 100644
> --- a/rust/Makefile
> +++ b/rust/Makefile
> @@ -421,7 +421,7 @@ ifneq ($(or $(CONFIG_ARM64),$(and $(CONFIG_RISCV),$(CONFIG_64BIT))),)
>  endif
>
>  $(obj)/core.o: private skip_clippy = 1
> -$(obj)/core.o: private skip_flags = -Dunreachable_pub
> +$(obj)/core.o: private skip_flags = -Wunreachable_pub
>  $(obj)/core.o: private rustc_objcopy = $(foreach sym,$(redirect-intrinsics),--redefine-sym $(sym)=__rust$(sym))
>  $(obj)/core.o: private rustc_target_flags = $(core-cfgs)
>  $(obj)/core.o: $(RUST_LIB_SRC)/core/src/lib.rs FORCE
> @@ -435,7 +435,7 @@ $(obj)/compiler_builtins.o: $(src)/compiler_builtins.rs $(obj)/core.o FORCE
>  	+$(call if_changed_dep,rustc_library)
>
>  $(obj)/alloc.o: private skip_clippy = 1
> -$(obj)/alloc.o: private skip_flags = -Dunreachable_pub
> +$(obj)/alloc.o: private skip_flags = -Wunreachable_pub
>  $(obj)/alloc.o: private rustc_target_flags = $(alloc-cfgs)
>  $(obj)/alloc.o: $(RUST_LIB_SRC)/alloc/src/lib.rs $(obj)/compiler_builtins.o FORCE
>  	+$(call if_changed_dep,rustc_library)
> -- 
> 2.45.2

[PATCH 05/13] rust: simplify Clippy warning flags set

[Miguel Ojeda]

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.

Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 Makefile | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index 056176a55d63..3f43f03f855e 100644
--- a/Makefile
+++ b/Makefile
@@ -465,10 +465,8 @@ export rust_common_flags := --edition=2021 \
 			    -Wunreachable_pub -Wnon_ascii_idents \
 			    -Wmissing_docs \
 			    -Wrustdoc::missing_crate_level_docs \
-			    -Wclippy::correctness -Wclippy::style \
-			    -Wclippy::suspicious -Wclippy::complexity \
-			    -Wclippy::perf \
-			    -Wclippy::let_unit_value -Wclippy::mut_mut \
+			    -Wclippy::all \
+			    -Wclippy::mut_mut \
 			    -Wclippy::needless_bitwise_bool \
 			    -Wclippy::needless_continue \
 			    -Wclippy::no_mangle_with_rust_abi \
-- 
2.45.2

Re: [PATCH 05/13] rust: simplify Clippy warning flags set

[Finn Behrens]

On 1 Jul 2024, at 20:36, Miguel Ojeda wrote:

> 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.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Reviewed-by: Finn Behrens <me@kloenk.dev>

> ---
>  Makefile | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 056176a55d63..3f43f03f855e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -465,10 +465,8 @@ export rust_common_flags := --edition=2021 \
>  			    -Wunreachable_pub -Wnon_ascii_idents \
>  			    -Wmissing_docs \
>  			    -Wrustdoc::missing_crate_level_docs \
> -			    -Wclippy::correctness -Wclippy::style \
> -			    -Wclippy::suspicious -Wclippy::complexity \
> -			    -Wclippy::perf \
> -			    -Wclippy::let_unit_value -Wclippy::mut_mut \
> +			    -Wclippy::all \
> +			    -Wclippy::mut_mut \
>  			    -Wclippy::needless_bitwise_bool \
>  			    -Wclippy::needless_continue \
>  			    -Wclippy::no_mangle_with_rust_abi \
> -- 
> 2.45.2

[PATCH 06/13] rust: start supporting several compiler versions

[Miguel Ojeda]

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]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 Documentation/process/changes.rst  | 4 +---
 Documentation/rust/quick-start.rst | 9 ++++-----
 scripts/rust_is_available.sh       | 8 --------
 scripts/rust_is_available_test.py  | 5 -----
 4 files changed, 5 insertions(+), 21 deletions(-)

diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
index 5685d7bfe4d0..0d0b7120792b 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -88,9 +88,7 @@ docs on :ref:`Building Linux with Clang/LLVM <kbuild_llvm>`.
 Rust (optional)
 ---------------
 
-A particular version of the Rust toolchain is required. Newer versions may or
-may not work because the kernel depends on some unstable Rust features, for
-the moment.
+A recent version of the Rust compiler is required.
 
 Each Rust toolchain comes with several "components", some of which are required
 (like ``rustc``) and some that are optional. The ``rust-src`` component (which
diff --git a/Documentation/rust/quick-start.rst b/Documentation/rust/quick-start.rst
index cc3f11e0d441..139a8a536838 100644
--- a/Documentation/rust/quick-start.rst
+++ b/Documentation/rust/quick-start.rst
@@ -29,16 +29,15 @@ if that is the case.
 rustc
 *****
 
-A particular version of the Rust compiler is required. Newer versions may or
-may not work because, for the moment, the kernel depends on some unstable
-Rust features.
+A recent version of the Rust compiler is required.
 
 If ``rustup`` is being used, enter the kernel build directory (or use
-``--path=<build-dir>`` argument to the ``set`` sub-command) and run::
+``--path=<build-dir>`` argument to the ``set`` sub-command) and run,
+for instance::
 
 	rustup override set $(scripts/min-tool-version.sh rustc)
 
-This will configure your working directory to use the correct version of
+This will configure your working directory to use the given version of
 ``rustc`` without affecting your default toolchain.
 
 Note that the override applies to the current working directory (and its
diff --git a/scripts/rust_is_available.sh b/scripts/rust_is_available.sh
index 117018946b57..67cb900124cc 100755
--- a/scripts/rust_is_available.sh
+++ b/scripts/rust_is_available.sh
@@ -117,14 +117,6 @@ if [ "$rust_compiler_cversion" -lt "$rust_compiler_min_cversion" ]; then
 	echo >&2 "***"
 	exit 1
 fi
-if [ "$rust_compiler_cversion" -gt "$rust_compiler_min_cversion" ]; then
-	echo >&2 "***"
-	echo >&2 "*** Rust compiler '$RUSTC' is too new. This may or may not work."
-	echo >&2 "***   Your version:     $rust_compiler_version"
-	echo >&2 "***   Expected version: $rust_compiler_min_version"
-	echo >&2 "***"
-	warning=1
-fi
 
 # Check that the Rust bindings generator is suitable.
 #
diff --git a/scripts/rust_is_available_test.py b/scripts/rust_is_available_test.py
index 57613fe5ed75..a255f79aafc2 100755
--- a/scripts/rust_is_available_test.py
+++ b/scripts/rust_is_available_test.py
@@ -193,11 +193,6 @@ else:
         result = self.run_script(self.Expected.FAILURE, { "RUSTC": rustc })
         self.assertIn(f"Rust compiler '{rustc}' is too old.", result.stderr)
 
-    def test_rustc_new_version(self):
-        rustc = self.generate_rustc("rustc 1.999.0 (a8314ef7d 2099-06-27)")
-        result = self.run_script(self.Expected.SUCCESS_WITH_WARNINGS, { "RUSTC": rustc })
-        self.assertIn(f"Rust compiler '{rustc}' is too new. This may or may not work.", result.stderr)
-
     def test_bindgen_nonexecutable(self):
         result = self.run_script(self.Expected.FAILURE, { "BINDGEN": self.nonexecutable })
         self.assertIn(f"Running '{self.nonexecutable}' to check the Rust bindings generator version failed with", result.stderr)
-- 
2.45.2

Re: [PATCH 06/13] rust: start supporting several compiler versions

[Miguel Ojeda]

On Thu, Jul 4, 2024 at 4:45 PM Finn Behrens <me@kloenk.dev> wrote:
>
> One idea below, but fine with or without it.
>
> Reviewed-by: Finn Behrens <me@kloenk.dev>

Thanks Finn!

> Would it make sense to not advise the min version but the “max” or just latest stable version? Min version should work as well latest could potentially be a bit more optimised if both work either way?

Yeah, that is a good idea -- we could just say `stable` there.

In fact, it makes more sense, because this is using `rustup`, i.e. the
Rust-provided binaries, and the Rust project only supports the latest
version (so far -- there are proposals about LTSs there).

Cheers,
Miguel

[PATCH 07/13] rust: warn about `bindgen` versions 0.66.0 and 0.66.1

[Miguel Ojeda]

`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.

We could make it an error, but 1) it is going to fail anyway later in the
build, 2) we would disable `RUST` automatically, which is also painful,
3) someone could be using a patched `bindgen` at that version, 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 test for the new case.

Link: https://github.com/rust-lang/rust-bindgen/pull/2567 [1]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 scripts/rust_is_available.sh      | 8 ++++++++
 scripts/rust_is_available_test.py | 7 +++++++
 2 files changed, 15 insertions(+)

diff --git a/scripts/rust_is_available.sh b/scripts/rust_is_available.sh
index 67cb900124cc..33bbd01ffe51 100755
--- a/scripts/rust_is_available.sh
+++ b/scripts/rust_is_available.sh
@@ -165,6 +165,14 @@ if [ "$rust_bindings_generator_cversion" -gt "$rust_bindings_generator_min_cvers
 	echo >&2 "***"
 	warning=1
 fi
+if [ "$rust_bindings_generator_cversion" -eq 6600 ] || [ "$rust_bindings_generator_cversion" -eq 6601 ]; then
+	echo >&2 "***"
+	echo >&2 "*** Rust bindings generator '$BINDGEN' versions 0.66.0 and 0.66.1 may not"
+	echo >&2 "*** work due to a bug (https://github.com/rust-lang/rust-bindgen/pull/2567)."
+	echo >&2 "***   Your version:     $rust_bindings_generator_version"
+	echo >&2 "***"
+	warning=1
+fi
 
 # Check that the `libclang` used by the Rust bindings generator is suitable.
 #
diff --git a/scripts/rust_is_available_test.py b/scripts/rust_is_available_test.py
index a255f79aafc2..2b887098c19d 100755
--- a/scripts/rust_is_available_test.py
+++ b/scripts/rust_is_available_test.py
@@ -226,6 +226,13 @@ else:
         result = self.run_script(self.Expected.SUCCESS_WITH_WARNINGS, { "BINDGEN": bindgen })
         self.assertIn(f"Rust bindings generator '{bindgen}' is too new. This may or may not work.", result.stderr)
 
+    def test_bindgen_bad_version_0_66_0_and_0_66_1(self):
+        for version in ("0.66.0", "0.66.1"):
+            with self.subTest(version=version):
+                bindgen = self.generate_bindgen_version(f"bindgen {version}")
+                result = self.run_script(self.Expected.SUCCESS_WITH_WARNINGS, { "BINDGEN": bindgen })
+                self.assertIn(f"Rust bindings generator '{bindgen}' versions 0.66.0 and 0.66.1 may not", result.stderr)
+
     def test_bindgen_libclang_failure(self):
         for env in (
             { "LLVM_CONFIG_PATH": self.missing },
-- 
2.45.2

Re: [PATCH 07/13] rust: warn about `bindgen` versions 0.66.0 and 0.66.1

[Finn Behrens]

On 1 Jul 2024, at 20:36, Miguel Ojeda wrote:

> `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.
>
> We could make it an error, but 1) it is going to fail anyway later in the
> build, 2) we would disable `RUST` automatically, which is also painful,
> 3) someone could be using a patched `bindgen` at that version, 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 test for the new case.
>
> Link: https://github.com/rust-lang/rust-bindgen/pull/2567 [1]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Reviewed-by: Finn Behrens <me@kloenk.dev>

> ---
>  scripts/rust_is_available.sh      | 8 ++++++++
>  scripts/rust_is_available_test.py | 7 +++++++
>  2 files changed, 15 insertions(+)
>
> diff --git a/scripts/rust_is_available.sh b/scripts/rust_is_available.sh
> index 67cb900124cc..33bbd01ffe51 100755
> --- a/scripts/rust_is_available.sh
> +++ b/scripts/rust_is_available.sh
> @@ -165,6 +165,14 @@ if [ "$rust_bindings_generator_cversion" -gt "$rust_bindings_generator_min_cvers
>  	echo >&2 "***"
>  	warning=1
>  fi
> +if [ "$rust_bindings_generator_cversion" -eq 6600 ] || [ "$rust_bindings_generator_cversion" -eq 6601 ]; then
> +	echo >&2 "***"
> +	echo >&2 "*** Rust bindings generator '$BINDGEN' versions 0.66.0 and 0.66.1 may not"
> +	echo >&2 "*** work due to a bug (https://github.com/rust-lang/rust-bindgen/pull/2567)."
> +	echo >&2 "***   Your version:     $rust_bindings_generator_version"
> +	echo >&2 "***"
> +	warning=1
> +fi
>
>  # Check that the `libclang` used by the Rust bindings generator is suitable.
>  #
> diff --git a/scripts/rust_is_available_test.py b/scripts/rust_is_available_test.py
> index a255f79aafc2..2b887098c19d 100755
> --- a/scripts/rust_is_available_test.py
> +++ b/scripts/rust_is_available_test.py
> @@ -226,6 +226,13 @@ else:
>          result = self.run_script(self.Expected.SUCCESS_WITH_WARNINGS, { "BINDGEN": bindgen })
>          self.assertIn(f"Rust bindings generator '{bindgen}' is too new. This may or may not work.", result.stderr)
>
> +    def test_bindgen_bad_version_0_66_0_and_0_66_1(self):
> +        for version in ("0.66.0", "0.66.1"):
> +            with self.subTest(version=version):
> +                bindgen = self.generate_bindgen_version(f"bindgen {version}")
> +                result = self.run_script(self.Expected.SUCCESS_WITH_WARNINGS, { "BINDGEN": bindgen })
> +                self.assertIn(f"Rust bindings generator '{bindgen}' versions 0.66.0 and 0.66.1 may not", result.stderr)
> +
>      def test_bindgen_libclang_failure(self):
>          for env in (
>              { "LLVM_CONFIG_PATH": self.missing },
> -- 
> 2.45.2

[PATCH 08/13] rust: work around `bindgen` 0.69.0 issue

[Miguel Ojeda]

`bindgen` 0.69.0 contains a bug: `--version` does not work without
providing a header [1]:

    error: the following required arguments were not provided:
      <HEADER>

    Usage: bindgen <FLAGS> <OPTIONS> <HEADER> -- <CLANG_ARGS>...

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]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 init/Kconfig                 | 5 ++++-
 scripts/rust_is_available.sh | 6 +++++-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index febdea2afc3b..94e20d3b99d4 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1928,7 +1928,10 @@ config RUSTC_VERSION_TEXT
 config BINDGEN_VERSION_TEXT
 	string
 	depends on RUST
-	default $(shell,command -v $(BINDGEN) >/dev/null 2>&1 && $(BINDGEN) --version || echo n)
+	# The dummy parameter `workaround-for-0.69.0` is required to support 0.69.0
+	# (https://github.com/rust-lang/rust-bindgen/pull/2678). It can be removed when
+	# the minimum version is upgraded past that (0.69.1 already fixed the issue).
+	default $(shell,command -v $(BINDGEN) >/dev/null 2>&1 && $(BINDGEN) --version workaround-for-0.69.0 || echo n)
 
 #
 # Place an empty function call at each tracepoint site. Can be
diff --git a/scripts/rust_is_available.sh b/scripts/rust_is_available.sh
index 33bbd01ffe51..cfda8157dce9 100755
--- a/scripts/rust_is_available.sh
+++ b/scripts/rust_is_available.sh
@@ -121,8 +121,12 @@ fi
 # Check that the Rust bindings generator is suitable.
 #
 # Non-stable and distributions' versions may have a version suffix, e.g. `-dev`.
+#
+# The dummy parameter `workaround-for-0.69.0` is required to support 0.69.0
+# (https://github.com/rust-lang/rust-bindgen/pull/2678). It can be removed when
+# the minimum version is upgraded past that (0.69.1 already fixed the issue).
 rust_bindings_generator_output=$( \
-	LC_ALL=C "$BINDGEN" --version 2>/dev/null
+	LC_ALL=C "$BINDGEN" --version workaround-for-0.69.0 2>/dev/null
 ) || rust_bindings_generator_code=$?
 if [ -n "$rust_bindings_generator_code" ]; then
 	echo >&2 "***"
-- 
2.45.2

Re: [PATCH 08/13] rust: work around `bindgen` 0.69.0 issue

[Finn Behrens]

On 1 Jul 2024, at 20:36, Miguel Ojeda wrote:

> `bindgen` 0.69.0 contains a bug: `--version` does not work without
> providing a header [1]:
>
>     error: the following required arguments were not provided:
>       <HEADER>
>
>     Usage: bindgen <FLAGS> <OPTIONS> <HEADER> -- <CLANG_ARGS>...
>
> 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]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Reviewed-by: Finn Behrens <me@kloenk.dev>

> ---
>  init/Kconfig                 | 5 ++++-
>  scripts/rust_is_available.sh | 6 +++++-
>  2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/init/Kconfig b/init/Kconfig
> index febdea2afc3b..94e20d3b99d4 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1928,7 +1928,10 @@ config RUSTC_VERSION_TEXT
>  config BINDGEN_VERSION_TEXT
>  	string
>  	depends on RUST
> -	default $(shell,command -v $(BINDGEN) >/dev/null 2>&1 && $(BINDGEN) --version || echo n)
> +	# The dummy parameter `workaround-for-0.69.0` is required to support 0.69.0
> +	# (https://github.com/rust-lang/rust-bindgen/pull/2678). It can be removed when
> +	# the minimum version is upgraded past that (0.69.1 already fixed the issue).
> +	default $(shell,command -v $(BINDGEN) >/dev/null 2>&1 && $(BINDGEN) --version workaround-for-0.69.0 || echo n)
>
>  #
>  # Place an empty function call at each tracepoint site. Can be
> diff --git a/scripts/rust_is_available.sh b/scripts/rust_is_available.sh
> index 33bbd01ffe51..cfda8157dce9 100755
> --- a/scripts/rust_is_available.sh
> +++ b/scripts/rust_is_available.sh
> @@ -121,8 +121,12 @@ fi
>  # Check that the Rust bindings generator is suitable.
>  #
>  # Non-stable and distributions' versions may have a version suffix, e.g. `-dev`.
> +#
> +# The dummy parameter `workaround-for-0.69.0` is required to support 0.69.0
> +# (https://github.com/rust-lang/rust-bindgen/pull/2678). It can be removed when
> +# the minimum version is upgraded past that (0.69.1 already fixed the issue).
>  rust_bindings_generator_output=$( \
> -	LC_ALL=C "$BINDGEN" --version 2>/dev/null
> +	LC_ALL=C "$BINDGEN" --version workaround-for-0.69.0 2>/dev/null
>  ) || rust_bindings_generator_code=$?
>  if [ -n "$rust_bindings_generator_code" ]; then
>  	echo >&2 "***"
> -- 
> 2.45.2

[PATCH 09/13] rust: avoid assuming a particular `bindgen` build

[Miguel Ojeda]

`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 build as well.

Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 Documentation/rust/quick-start.rst | 23 +++++++++--------------
 scripts/rust_is_available_test.py  | 25 +++++++++++++++----------
 2 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/Documentation/rust/quick-start.rst b/Documentation/rust/quick-start.rst
index 139a8a536838..f411cad4cc02 100644
--- a/Documentation/rust/quick-start.rst
+++ b/Documentation/rust/quick-start.rst
@@ -106,20 +106,15 @@ Install it via (note that this will download and build the tool from source)::
 
 	cargo install --locked --version $(scripts/min-tool-version.sh bindgen) bindgen-cli
 
-``bindgen`` needs to find a suitable ``libclang`` in order to work. If it is
-not found (or a different ``libclang`` than the one found should be used),
-the process can be tweaked using the environment variables understood by
-``clang-sys`` (the Rust bindings crate that ``bindgen`` uses to access
-``libclang``):
-
-* ``LLVM_CONFIG_PATH`` can be pointed to an ``llvm-config`` executable.
-
-* Or ``LIBCLANG_PATH`` can be pointed to a ``libclang`` shared library
-  or to the directory containing it.
-
-* Or ``CLANG_PATH`` can be pointed to a ``clang`` executable.
-
-For details, please see ``clang-sys``'s documentation at:
+``bindgen`` uses the ``clang-sys`` crate to find a suitable ``libclang`` (which
+may be linked statically, dynamically or loaded at runtime). By default, the
+``cargo`` command above will produce a ``bindgen`` binary that will load
+``libclang`` at runtime. If it is not found (or a different ``libclang`` than
+the one found should be used), the process can be tweaked, e.g. by using the
+``LIBCLANG_PATH`` environment variable. For details, please see ``clang-sys``'s
+documentation at:
+
+	https://github.com/KyleMayes/clang-sys#linking
 
 	https://github.com/KyleMayes/clang-sys#environment-variables
 
diff --git a/scripts/rust_is_available_test.py b/scripts/rust_is_available_test.py
index 2b887098c19d..f5ebafff002c 100755
--- a/scripts/rust_is_available_test.py
+++ b/scripts/rust_is_available_test.py
@@ -55,10 +55,15 @@ else:
 
     @classmethod
     def generate_bindgen(cls, version_stdout, libclang_stderr):
+        if libclang_stderr is None:
+            libclang_case = f"raise SystemExit({cls.bindgen_default_bindgen_libclang_failure_exit_code})"
+        else:
+            libclang_case = f"print({repr(libclang_stderr)}, file=sys.stderr)"
+
         return cls.generate_executable(f"""#!/usr/bin/env python3
 import sys
 if "rust_is_available_bindgen_libclang.h" in " ".join(sys.argv):
-    print({repr(libclang_stderr)}, file=sys.stderr)
+    {libclang_case}
 else:
     print({repr(version_stdout)})
 """)
@@ -67,6 +72,10 @@ else:
     def generate_bindgen_version(cls, stdout):
         return cls.generate_bindgen(stdout, cls.bindgen_default_bindgen_libclang_stderr)
 
+    @classmethod
+    def generate_bindgen_libclang_failure(cls):
+        return cls.generate_bindgen(cls.bindgen_default_bindgen_version_stdout, None)
+
     @classmethod
     def generate_bindgen_libclang(cls, stderr):
         return cls.generate_bindgen(cls.bindgen_default_bindgen_version_stdout, stderr)
@@ -89,6 +98,7 @@ else:
         cls.rust_default_sysroot = subprocess.check_output(("rustc", "--print", "sysroot")).decode().strip()
 
         cls.bindgen_default_bindgen_version_stdout = f"bindgen {cls.bindgen_default_version}"
+        cls.bindgen_default_bindgen_libclang_failure_exit_code = 42
         cls.bindgen_default_bindgen_libclang_stderr = f"scripts/rust_is_available_bindgen_libclang.h:2:9: warning: clang version {cls.llvm_default_version} [-W#pragma-messages], err: false"
 
         cls.default_rustc = cls.generate_rustc(f"rustc {cls.rustc_default_version}")
@@ -234,15 +244,10 @@ else:
                 self.assertIn(f"Rust bindings generator '{bindgen}' versions 0.66.0 and 0.66.1 may not", result.stderr)
 
     def test_bindgen_libclang_failure(self):
-        for env in (
-            { "LLVM_CONFIG_PATH": self.missing },
-            { "LIBCLANG_PATH": self.missing },
-            { "CLANG_PATH": self.missing },
-        ):
-            with self.subTest(env=env):
-                result = self.run_script(self.Expected.FAILURE, env | { "PATH": os.environ["PATH"], "BINDGEN": "bindgen" })
-                self.assertIn("Running 'bindgen' to check the libclang version (used by the Rust", result.stderr)
-                self.assertIn("bindings generator) failed with code ", result.stderr)
+        bindgen = self.generate_bindgen_libclang_failure()
+        result = self.run_script(self.Expected.FAILURE, { "BINDGEN": bindgen })
+        self.assertIn(f"Running '{bindgen}' to check the libclang version (used by the Rust", result.stderr)
+        self.assertIn(f"bindings generator) failed with code {self.bindgen_default_bindgen_libclang_failure_exit_code}. This may be caused by", result.stderr)
 
     def test_bindgen_libclang_unexpected_version(self):
         bindgen = self.generate_bindgen_libclang("scripts/rust_is_available_bindgen_libclang.h:2:9: warning: clang version unexpected [-W#pragma-messages], err: false")
-- 
2.45.2

[PATCH 10/13] rust: start supporting several `bindgen` versions

[Miguel Ojeda]

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]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 Documentation/rust/quick-start.rst | 5 +++--
 scripts/rust_is_available.sh       | 8 --------
 scripts/rust_is_available_test.py  | 5 -----
 3 files changed, 3 insertions(+), 15 deletions(-)

diff --git a/Documentation/rust/quick-start.rst b/Documentation/rust/quick-start.rst
index f411cad4cc02..f624b913ff89 100644
--- a/Documentation/rust/quick-start.rst
+++ b/Documentation/rust/quick-start.rst
@@ -100,9 +100,10 @@ bindgen
 *******
 
 The bindings to the C side of the kernel are generated at build time using
-the ``bindgen`` tool. A particular version is required.
+the ``bindgen`` tool.
 
-Install it via (note that this will download and build the tool from source)::
+Install it, for instance, via (note that this will download and build the tool
+from source)::
 
 	cargo install --locked --version $(scripts/min-tool-version.sh bindgen) bindgen-cli
 
diff --git a/scripts/rust_is_available.sh b/scripts/rust_is_available.sh
index cfda8157dce9..537accc73334 100755
--- a/scripts/rust_is_available.sh
+++ b/scripts/rust_is_available.sh
@@ -161,14 +161,6 @@ if [ "$rust_bindings_generator_cversion" -lt "$rust_bindings_generator_min_cvers
 	echo >&2 "***"
 	exit 1
 fi
-if [ "$rust_bindings_generator_cversion" -gt "$rust_bindings_generator_min_cversion" ]; then
-	echo >&2 "***"
-	echo >&2 "*** Rust bindings generator '$BINDGEN' is too new. This may or may not work."
-	echo >&2 "***   Your version:     $rust_bindings_generator_version"
-	echo >&2 "***   Expected version: $rust_bindings_generator_min_version"
-	echo >&2 "***"
-	warning=1
-fi
 if [ "$rust_bindings_generator_cversion" -eq 6600 ] || [ "$rust_bindings_generator_cversion" -eq 6601 ]; then
 	echo >&2 "***"
 	echo >&2 "*** Rust bindings generator '$BINDGEN' versions 0.66.0 and 0.66.1 may not"
diff --git a/scripts/rust_is_available_test.py b/scripts/rust_is_available_test.py
index f5ebafff002c..927cd8bbc09c 100755
--- a/scripts/rust_is_available_test.py
+++ b/scripts/rust_is_available_test.py
@@ -231,11 +231,6 @@ else:
         result = self.run_script(self.Expected.FAILURE, { "BINDGEN": bindgen })
         self.assertIn(f"Rust bindings generator '{bindgen}' is too old.", result.stderr)
 
-    def test_bindgen_new_version(self):
-        bindgen = self.generate_bindgen_version("bindgen 0.999.0")
-        result = self.run_script(self.Expected.SUCCESS_WITH_WARNINGS, { "BINDGEN": bindgen })
-        self.assertIn(f"Rust bindings generator '{bindgen}' is too new. This may or may not work.", result.stderr)
-
     def test_bindgen_bad_version_0_66_0_and_0_66_1(self):
         for version in ("0.66.0", "0.66.1"):
             with self.subTest(version=version):
-- 
2.45.2

[PATCH 11/13] kbuild: rust: add `rustc-version` support

[Miguel Ojeda]

Now that we are starting to support several Rust versions, introduce
`rustc-version` support, mimicking the C side:

  - `scripts/rustc-version.sh`, that mimics the other version scripts
     (with one more digit, e.g. Rust 1.79.0 is 107900).

  - `rustc-{info,name,version}` Kbuild macros.

  - `CONFIG_RUSTC_VERSION` Kconfig symbol that calls `rustc-version`.

  - `rustc-min-version` Kbuild macro that uses `CONFIG_RUSTC_VERSION`.

With these, we can easily support flags conditionally depending on
`rustc`'s version -- a user comes in the next patch.

Another user will be the `-Ctarget-feature=+reserve-x18`/`-Zfixed-x18`
arm64 flags [1].

Link: https://lore.kernel.org/rust-for-linux/20240305-shadow-call-stack-v2-1-c7b4a3f4d616@google.com/ [1]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 init/Kconfig              |  6 +++++
 scripts/Kconfig.include   |  6 +++++
 scripts/Makefile.compiler |  4 +++
 scripts/rustc-version.sh  | 52 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 68 insertions(+)
 create mode 100755 scripts/rustc-version.sh

diff --git a/init/Kconfig b/init/Kconfig
index 94e20d3b99d4..7d344f248785 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1920,6 +1920,12 @@ config RUST
 
 	  If unsure, say N.
 
+config RUSTC_VERSION
+	int
+	depends on RUST
+	default $(rustc-version)
+	default 0
+
 config RUSTC_VERSION_TEXT
 	string
 	depends on RUST
diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
index 3ee8ecfb8c04..82ab889725db 100644
--- a/scripts/Kconfig.include
+++ b/scripts/Kconfig.include
@@ -45,6 +45,12 @@ $(error-if,$(success,test -z "$(cc-info)"),Sorry$(comma) this C compiler is not
 cc-name := $(shell,set -- $(cc-info) && echo $1)
 cc-version := $(shell,set -- $(cc-info) && echo $2)
 
+# Get the Rust compiler name, version, and error out if it is not supported.
+rustc-info := $(shell,$(srctree)/scripts/rustc-version.sh $(RUSTC))
+$(error-if,$(success,test -z "$(rustc-info)"),Sorry$(comma) this Rust compiler is not supported.)
+rustc-name := $(shell,set -- $(rustc-info) && echo $1)
+rustc-version := $(shell,set -- $(rustc-info) && echo $2)
+
 # Get the assembler name, version, and error out if it is not supported.
 as-info := $(shell,$(srctree)/scripts/as-version.sh $(CC) $(CLANG_FLAGS))
 $(error-if,$(success,test -z "$(as-info)"),Sorry$(comma) this assembler is not supported.)
diff --git a/scripts/Makefile.compiler b/scripts/Makefile.compiler
index 92be0c9a13ee..17eaa085b59c 100644
--- a/scripts/Makefile.compiler
+++ b/scripts/Makefile.compiler
@@ -69,6 +69,10 @@ gcc-min-version = $(call test-ge, $(CONFIG_GCC_VERSION), $1)
 # Usage: cflags-$(call clang-min-version, 110000) += -foo
 clang-min-version = $(call test-ge, $(CONFIG_CLANG_VERSION), $1)
 
+# rustc-min-version
+# Usage: rustflags-$(call rustc-min-version, 107900) += -foo
+rustc-min-version = $(call test-ge, $(CONFIG_RUSTC_VERSION), $1)
+
 # ld-option
 # Usage: KBUILD_LDFLAGS += $(call ld-option, -X, -Y)
 ld-option = $(call try-run, $(LD) $(KBUILD_LDFLAGS) $(1) -v,$(1),$(2),$(3))
diff --git a/scripts/rustc-version.sh b/scripts/rustc-version.sh
new file mode 100755
index 000000000000..4e658fd55ae6
--- /dev/null
+++ b/scripts/rustc-version.sh
@@ -0,0 +1,52 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+#
+# Print the Rust compiler name and its version in a 5 or 6-digit form.
+# Also, perform the minimum version check.
+
+set -e
+
+# Convert the version string x.y.z to a canonical up-to-7-digits form.
+#
+# Note that this function uses one more digit (compared to other
+# instances in other version scripts) to give a bit more space to
+# `rustc` since it will reach 1.100.0 in late 2026.
+get_canonical_version()
+{
+	IFS=.
+	set -- $1
+	echo $((100000 * $1 + 100 * $2 + $3))
+}
+
+orig_args="$@"
+
+set -- $("$@" --version)
+
+name=$1
+
+min_tool_version=$(dirname $0)/min-tool-version.sh
+
+case "$name" in
+rustc)
+	version=$2
+	min_version=$($min_tool_version rustc)
+	;;
+*)
+	echo "$orig_args: unknown Rust compiler" >&2
+	exit 1
+	;;
+esac
+
+rustcversion=$(get_canonical_version $version)
+min_rustcversion=$(get_canonical_version $min_version)
+
+if [ "$rustcversion" -lt "$min_rustcversion" ]; then
+	echo >&2 "***"
+	echo >&2 "*** Rust compiler is too old."
+	echo >&2 "***   Your $name version:    $version"
+	echo >&2 "***   Minimum $name version: $min_version"
+	echo >&2 "***"
+	exit 1
+fi
+
+echo $name $rustcversion
-- 
2.45.2

Re: [PATCH 11/13] kbuild: rust: add `rustc-version` support

[Finn Behrens]

On 1 Jul 2024, at 20:36, Miguel Ojeda wrote:

> Now that we are starting to support several Rust versions, introduce
> `rustc-version` support, mimicking the C side:
>
>   - `scripts/rustc-version.sh`, that mimics the other version scripts
>      (with one more digit, e.g. Rust 1.79.0 is 107900).
>
>   - `rustc-{info,name,version}` Kbuild macros.
>
>   - `CONFIG_RUSTC_VERSION` Kconfig symbol that calls `rustc-version`.
>
>   - `rustc-min-version` Kbuild macro that uses `CONFIG_RUSTC_VERSION`.
>
> With these, we can easily support flags conditionally depending on
> `rustc`'s version -- a user comes in the next patch.
>
> Another user will be the `-Ctarget-feature=+reserve-x18`/`-Zfixed-x18`
> arm64 flags [1].
>
> Link: https://lore.kernel.org/rust-for-linux/20240305-shadow-call-stack-v2-1-c7b4a3f4d616@google.com/ [1]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Reviewed-by: Finn Behrens <me@kloenk.dev>

> ---
>  init/Kconfig              |  6 +++++
>  scripts/Kconfig.include   |  6 +++++
>  scripts/Makefile.compiler |  4 +++
>  scripts/rustc-version.sh  | 52 +++++++++++++++++++++++++++++++++++++++
>  4 files changed, 68 insertions(+)
>  create mode 100755 scripts/rustc-version.sh
>
> diff --git a/init/Kconfig b/init/Kconfig
> index 94e20d3b99d4..7d344f248785 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1920,6 +1920,12 @@ config RUST
>
>  	  If unsure, say N.
>
> +config RUSTC_VERSION
> +	int
> +	depends on RUST
> +	default $(rustc-version)
> +	default 0
> +
>  config RUSTC_VERSION_TEXT
>  	string
>  	depends on RUST
> diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
> index 3ee8ecfb8c04..82ab889725db 100644
> --- a/scripts/Kconfig.include
> +++ b/scripts/Kconfig.include
> @@ -45,6 +45,12 @@ $(error-if,$(success,test -z "$(cc-info)"),Sorry$(comma) this C compiler is not
>  cc-name := $(shell,set -- $(cc-info) && echo $1)
>  cc-version := $(shell,set -- $(cc-info) && echo $2)
>
> +# Get the Rust compiler name, version, and error out if it is not supported.
> +rustc-info := $(shell,$(srctree)/scripts/rustc-version.sh $(RUSTC))
> +$(error-if,$(success,test -z "$(rustc-info)"),Sorry$(comma) this Rust compiler is not supported.)
> +rustc-name := $(shell,set -- $(rustc-info) && echo $1)
> +rustc-version := $(shell,set -- $(rustc-info) && echo $2)
> +
>  # Get the assembler name, version, and error out if it is not supported.
>  as-info := $(shell,$(srctree)/scripts/as-version.sh $(CC) $(CLANG_FLAGS))
>  $(error-if,$(success,test -z "$(as-info)"),Sorry$(comma) this assembler is not supported.)
> diff --git a/scripts/Makefile.compiler b/scripts/Makefile.compiler
> index 92be0c9a13ee..17eaa085b59c 100644
> --- a/scripts/Makefile.compiler
> +++ b/scripts/Makefile.compiler
> @@ -69,6 +69,10 @@ gcc-min-version = $(call test-ge, $(CONFIG_GCC_VERSION), $1)
>  # Usage: cflags-$(call clang-min-version, 110000) += -foo
>  clang-min-version = $(call test-ge, $(CONFIG_CLANG_VERSION), $1)
>
> +# rustc-min-version
> +# Usage: rustflags-$(call rustc-min-version, 107900) += -foo
> +rustc-min-version = $(call test-ge, $(CONFIG_RUSTC_VERSION), $1)
> +
>  # ld-option
>  # Usage: KBUILD_LDFLAGS += $(call ld-option, -X, -Y)
>  ld-option = $(call try-run, $(LD) $(KBUILD_LDFLAGS) $(1) -v,$(1),$(2),$(3))
> diff --git a/scripts/rustc-version.sh b/scripts/rustc-version.sh
> new file mode 100755
> index 000000000000..4e658fd55ae6
> --- /dev/null
> +++ b/scripts/rustc-version.sh
> @@ -0,0 +1,52 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# Print the Rust compiler name and its version in a 5 or 6-digit form.
> +# Also, perform the minimum version check.
> +
> +set -e
> +
> +# Convert the version string x.y.z to a canonical up-to-7-digits form.
> +#
> +# Note that this function uses one more digit (compared to other
> +# instances in other version scripts) to give a bit more space to
> +# `rustc` since it will reach 1.100.0 in late 2026.
> +get_canonical_version()
> +{
> +	IFS=.
> +	set -- $1
> +	echo $((100000 * $1 + 100 * $2 + $3))
> +}
> +
> +orig_args="$@"
> +
> +set -- $("$@" --version)
> +
> +name=$1
> +
> +min_tool_version=$(dirname $0)/min-tool-version.sh
> +
> +case "$name" in
> +rustc)
> +	version=$2
> +	min_version=$($min_tool_version rustc)
> +	;;
> +*)
> +	echo "$orig_args: unknown Rust compiler" >&2
> +	exit 1
> +	;;
> +esac
> +
> +rustcversion=$(get_canonical_version $version)
> +min_rustcversion=$(get_canonical_version $min_version)
> +
> +if [ "$rustcversion" -lt "$min_rustcversion" ]; then
> +	echo >&2 "***"
> +	echo >&2 "*** Rust compiler is too old."
> +	echo >&2 "***   Your $name version:    $version"
> +	echo >&2 "***   Minimum $name version: $min_version"
> +	echo >&2 "***"
> +	exit 1
> +fi
> +
> +echo $name $rustcversion
> -- 
> 2.45.2

[PATCH 12/13] rust: support the new `-Zub-checks` flag

[Miguel Ojeda]

Rust 1.79.0 has introduced a new codegen flag, `-Zub-checks` [1], to
allow to independently configure (from `-Cdebug-assertions`) whether the
extra runtime checks for UB are emitted, in a similar fashion to
`-Coverflow-checks`.

This allows to configure the kernel with only the UB checks enabled,
but not the `debug_assert!`s; or vice versa, e.g. [2].

It also showcases how `RUSTC_VERSION` and the Kbuild macros, introduced
in the previous commit, can be used.

Link: https://github.com/rust-lang/compiler-team/issues/725 [1]
Link: https://godbolt.org/z/jY69ezx5K [2]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 Makefile          |  9 +++++++--
 lib/Kconfig.debug | 18 ++++++++++++++++++
 2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 3f43f03f855e..c0cb5c237c26 100644
--- a/Makefile
+++ b/Makefile
@@ -820,10 +820,15 @@ KBUILD_CFLAGS += -Os
 KBUILD_RUSTFLAGS += -Copt-level=s
 endif
 
-# Always set `debug-assertions` and `overflow-checks` because their default
-# depends on `opt-level` and `debug-assertions`, respectively.
+# Always set `debug-assertions` because its default depends on `opt-level`.
 KBUILD_RUSTFLAGS += -Cdebug-assertions=$(if $(CONFIG_RUST_DEBUG_ASSERTIONS),y,n)
+
+# Always set `overflow-checks` and `ub-checks` because their default depends on
+# `debug-assertions`.
 KBUILD_RUSTFLAGS += -Coverflow-checks=$(if $(CONFIG_RUST_OVERFLOW_CHECKS),y,n)
+ifeq ($(call rustc-min-version, 107900),y)
+KBUILD_RUSTFLAGS += -Zub-checks=$(if $(CONFIG_RUST_UNDEFINED_BEHAVIOR_CHECKS),y,n)
+endif
 
 # Tell gcc to never replace conditional load with a non-conditional one
 ifdef CONFIG_CC_IS_GCC
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 59b6765d86b8..6b4f512f9e13 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -3020,6 +3020,24 @@ config RUST_OVERFLOW_CHECKS
 
 	  If unsure, say Y.
 
+config RUST_UNDEFINED_BEHAVIOR_CHECKS
+	bool "Undefined Behavior checks"
+	depends on RUST && RUSTC_VERSION >= 107900
+	help
+	  Enables rustc's `-Zub-checks` codegen option.
+
+	  This flag allows you to control whether additional runtime checks that
+	  detect some causes of Undefined Behavior at runtime will be emitted.
+	  When enabled, a Rust panic will occur if UB is detected.
+
+	  All checks are generated on a best-effort basis; even if there is a check
+	  implemented for some cause of Undefined Behavior, it may be possible for
+	  the check to not fire.
+
+	  Note that this will apply to all Rust code, including `core`.
+
+	  If unsure, say N.
+
 config RUST_BUILD_ASSERT_ALLOW
 	bool "Allow unoptimized build-time assertions"
 	depends on RUST
-- 
2.45.2

Re: [PATCH 12/13] rust: support the new `-Zub-checks` flag

[Finn Behrens]

On 1 Jul 2024, at 20:36, Miguel Ojeda wrote:

> Rust 1.79.0 has introduced a new codegen flag, `-Zub-checks` [1], to
> allow to independently configure (from `-Cdebug-assertions`) whether the
> extra runtime checks for UB are emitted, in a similar fashion to
> `-Coverflow-checks`.
>
> This allows to configure the kernel with only the UB checks enabled,
> but not the `debug_assert!`s; or vice versa, e.g. [2].
>
> It also showcases how `RUSTC_VERSION` and the Kbuild macros, introduced
> in the previous commit, can be used.
>
> Link: https://github.com/rust-lang/compiler-team/issues/725 [1]
> Link: https://godbolt.org/z/jY69ezx5K [2]
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Reviewed-by: Finn Behrens <me@kloenk.dev>

> ---
>  Makefile          |  9 +++++++--
>  lib/Kconfig.debug | 18 ++++++++++++++++++
>  2 files changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 3f43f03f855e..c0cb5c237c26 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -820,10 +820,15 @@ KBUILD_CFLAGS += -Os
>  KBUILD_RUSTFLAGS += -Copt-level=s
>  endif
>
> -# Always set `debug-assertions` and `overflow-checks` because their default
> -# depends on `opt-level` and `debug-assertions`, respectively.
> +# Always set `debug-assertions` because its default depends on `opt-level`.
>  KBUILD_RUSTFLAGS += -Cdebug-assertions=$(if $(CONFIG_RUST_DEBUG_ASSERTIONS),y,n)
> +
> +# Always set `overflow-checks` and `ub-checks` because their default depends on
> +# `debug-assertions`.
>  KBUILD_RUSTFLAGS += -Coverflow-checks=$(if $(CONFIG_RUST_OVERFLOW_CHECKS),y,n)
> +ifeq ($(call rustc-min-version, 107900),y)
> +KBUILD_RUSTFLAGS += -Zub-checks=$(if $(CONFIG_RUST_UNDEFINED_BEHAVIOR_CHECKS),y,n)
> +endif
>
>  # Tell gcc to never replace conditional load with a non-conditional one
>  ifdef CONFIG_CC_IS_GCC
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 59b6765d86b8..6b4f512f9e13 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -3020,6 +3020,24 @@ config RUST_OVERFLOW_CHECKS
>
>  	  If unsure, say Y.
>
> +config RUST_UNDEFINED_BEHAVIOR_CHECKS
> +	bool "Undefined Behavior checks"
> +	depends on RUST && RUSTC_VERSION >= 107900
> +	help
> +	  Enables rustc's `-Zub-checks` codegen option.
> +
> +	  This flag allows you to control whether additional runtime checks that
> +	  detect some causes of Undefined Behavior at runtime will be emitted.
> +	  When enabled, a Rust panic will occur if UB is detected.
> +
> +	  All checks are generated on a best-effort basis; even if there is a check
> +	  implemented for some cause of Undefined Behavior, it may be possible for
> +	  the check to not fire.
> +
> +	  Note that this will apply to all Rust code, including `core`.
> +
> +	  If unsure, say N.
> +
>  config RUST_BUILD_ASSERT_ALLOW
>  	bool "Allow unoptimized build-time assertions"
>  	depends on RUST
> -- 
> 2.45.2

[PATCH 13/13] docs: rust: quick-start: add section on Linux distributions

[Miguel Ojeda]

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. We may want to reorganize it 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 <heftig@archlinux.org>
Cc: Johannes Löthberg <johannes@kyriasis.com>
Cc: Fabian Grünbichler <debian@fabian.gruenbichler.email>
Cc: Josh Stone <jistone@redhat.com>
Cc: Randy Barlow <randy@electronsweatshop.com>
Cc: Anna (navi) Figueiredo Gomes <navi@vlhl.dev>
Cc: Matoro Mahri <matoro_gentoo@matoro.tk>
Cc: Ryan Scheel <ryan.havvy@gmail.com>
Cc: figsoda <figsoda@pm.me>
Cc: Jörg Thalheim <joerg@thalheim.io>
Cc: Theodore Ni <43ngvg@masqt.com>
Cc: Winter <nixos@winter.cafe>
Cc: William Brown <wbrown@suse.de>
Cc: Xiaoguang Wang <xiaoguang.wang@suse.com>
Cc: Andrea Righi <andrea.righi@canonical.com>
Cc: Zixing Liu <zixing.liu@canonical.com>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
Note that openSUSE Tumbleweed is adding the Rust standard library source
code, `rustfmt` and Clippy, so we may be able to drop that small note in
their section in a few days (possibly before this gets applied) --
thanks William!

 Documentation/process/changes.rst  |  5 --
 Documentation/rust/quick-start.rst | 83 ++++++++++++++++++++++++++++--
 2 files changed, 78 insertions(+), 10 deletions(-)

diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
index 0d0b7120792b..0ce96ae2588c 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -90,11 +90,6 @@ Rust (optional)
 
 A recent version of the Rust compiler is required.
 
-Each Rust toolchain comes with several "components", some of which are required
-(like ``rustc``) and some that are optional. The ``rust-src`` component (which
-is optional) needs to be installed to build the kernel. Other components are
-useful for developing.
-
 Please see Documentation/rust/quick-start.rst for instructions on how to
 satisfy the build requirements of Rust support. In particular, the ``Makefile``
 target ``rustavailable`` is useful to check why the Rust toolchain may not
diff --git a/Documentation/rust/quick-start.rst b/Documentation/rust/quick-start.rst
index f624b913ff89..65a34a9a7089 100644
--- a/Documentation/rust/quick-start.rst
+++ b/Documentation/rust/quick-start.rst
@@ -5,17 +5,90 @@ Quick Start
 
 This document describes how to get started with kernel development in Rust.
 
+There are a few ways to install a Rust toolchain needed for kernel development.
+A simple way is to use the packages from your Linux distribution if they are
+suitable -- the first section below explains this approach. An advantage of this
+approach is that, typically, the distribution will match the LLVM used by Rust
+and Clang.
+
+Alternatively, the next two "Requirements" sections explain each component and
+how to install them through ``rustup``, the standalone installers from Rust
+and/or building them.
+
+The rest of the document explains other aspects on how to get started.
+
+
+Distributions
+-------------
+
+Arch Linux
+**********
+
+Arch Linux provides recent Rust releases and thus it should generally work out
+of the box, e.g.::
+
+	pacman -S rust rust-src rust-bindgen
+
+
+Debian
+******
+
+Debian Unstable (Sid), outside of the freeze period, provides recent Rust
+release and thus it should generally work out of the box, e.g.::
+
+	apt install rustc rust-src bindgen rustfmt rust-clippy
+
+
+Fedora Linux
+************
+
+Fedora Linux provides recent Rust releases and thus it should generally work out
+of the box, e.g.::
+
+	dnf install rust rust-src bindgen-cli rustfmt clippy
+
+
+Gentoo Linux
+************
+
+Gentoo Linux (and especially the testing branch) provides recent Rust releases
+and thus it should generally work out of the box, e.g.::
+
+	USE='rust-src rustfmt clippy' emerge dev-lang/rust dev-util/bindgen
+
+``LIBCLANG_PATH`` may need to be set.
+
+
+Nix
+***
+
+Nix (unstable channel) provides recent Rust releases and thus it should
+generally work out of the box, e.g.::
+
+	{ pkgs ? import <nixpkgs> {} }:
+	pkgs.mkShell {
+	  nativeBuildInputs = with pkgs; [ rustc rust-bindgen rustfmt clippy ];
+	  RUST_LIB_SRC = "${pkgs.rust.packages.stable.rustPlatform.rustLibSrc}";
+	}
+
+
+openSUSE
+********
+
+openSUSE Tumbleweed provides recent Rust releases and thus it should generally
+work out of the box, e.g.::
+
+	zypper install rust rust-bindgen clang
+
+The Rust standard library source code, ``rustfmt`` and Clippy are not packaged
+(yet), thus currently they need to be installed separately.
+
 
 Requirements: Building
 ----------------------
 
 This section explains how to fetch the tools needed for building.
 
-Some of these requirements might be available from Linux distributions
-under names like ``rustc``, ``rust-src``, ``rust-bindgen``, etc. However,
-at the time of writing, they are likely not to be recent enough unless
-the distribution tracks the latest releases.
-
 To easily check whether the requirements are met, the following target
 can be used::
 
-- 
2.45.2

Re: [PATCH 13/13] docs: rust: quick-start: add section on Linux distributions

[Andrea Righi]

On Mon, Jul 01, 2024 at 08:36:23PM +0200, Miguel Ojeda wrote:
..
> +Debian
> +******
> +
> +Debian Unstable (Sid), outside of the freeze period, provides recent Rust
> +release and thus it should generally work out of the box, e.g.::
> +
> +	apt install rustc rust-src bindgen rustfmt rust-clippy

This implicitly covers Ubuntu, since packages are sync'ed with Debian.

In addition to that Ubuntu also provides versioned packages (such as
rustc-1.74, bindgen-0.65, etc.), so in case of special requirements
(e.g., older kernels) users should be able to install the required
version(s) using the packages provided by the distro.

Maybe it's worth mentioning as a little note, so that users are aware of
these extra packages.

Thanks,
-Andrea

Re: [PATCH 13/13] docs: rust: quick-start: add section on Linux distributions

[Fabian Grünbichler]

On Fri, Jul 05, 2024 at 08:19:01AM GMT, Andrea Righi wrote:
> On Mon, Jul 01, 2024 at 08:36:23PM +0200, Miguel Ojeda wrote:
> ..
> > +Debian
> > +******
> > +
> > +Debian Unstable (Sid), outside of the freeze period, provides recent Rust
> > +release and thus it should generally work out of the box, e.g.::
> > +
> > +	apt install rustc rust-src bindgen rustfmt rust-clippy
> 
> This implicitly covers Ubuntu, since packages are sync'ed with Debian.
> 
> In addition to that Ubuntu also provides versioned packages (such as
> rustc-1.74, bindgen-0.65, etc.), so in case of special requirements
> (e.g., older kernels) users should be able to install the required
> version(s) using the packages provided by the distro.

Debian (for building firefox and chromium), and uses a -web suffix for
that:

https://tracker.debian.org/pkg/rustc-web
https://tracker.debian.org/pkg/rust-cbindgen-web

cheers,
Fabian

Re: [PATCH 13/13] docs: rust: quick-start: add section on Linux distributions

[Miguel Ojeda]

On Fri, Jul 5, 2024 at 8:47 AM Fabian Grünbichler
<debian@fabian.gruenbichler.email> wrote:
>
> Debian (for building firefox and chromium), and uses a -web suffix for
> that:
>
> https://tracker.debian.org/pkg/rustc-web

Like for Ubuntu's versioned ones, it seems not recent enough at the
moment (i.e. for the current kernel), if I understand correctly.

Also, it is a single version, i.e. 1.70, right? We didn't use that
particular version in any old kernel version (we moved from 1.68.2 to
1.71.1 in commit 89eed1ab1161 ("rust: upgrade to Rust 1.71.1") back
then). So I am not sure how useful it would be, but if you think it
will be in the future, perhaps it is worth mentioning.

> https://tracker.debian.org/pkg/rust-cbindgen-web

We may use `cbindgen` too in the future, but not currently.

Is something like `bindgen-web` also available for stable?

Thanks!

Cheers,
Miguel

Re: [PATCH 13/13] docs: rust: quick-start: add section on Linux distributions

[Fabian Grünbichler]

On Fri, Jul 05, 2024 at 02:52:44PM GMT, Miguel Ojeda wrote:
> On Fri, Jul 5, 2024 at 8:47 AM Fabian Grünbichler
> <debian@fabian.gruenbichler.email> wrote:
> >
> > Debian (for building firefox and chromium), and uses a -web suffix for
> > that:
> >
> > https://tracker.debian.org/pkg/rustc-web
> 
> Like for Ubuntu's versioned ones, it seems not recent enough at the
> moment (i.e. for the current kernel), if I understand correctly.

yep.

> Also, it is a single version, i.e. 1.70, right? We didn't use that
> particular version in any old kernel version (we moved from 1.68.2 to
> 1.71.1 in commit 89eed1ab1161 ("rust: upgrade to Rust 1.71.1") back
> then). So I am not sure how useful it would be, but if you think it
> will be in the future, perhaps it is worth mentioning.

right now it is updated whenever its rdeps (firefox and chromium in
stable) need newer versions. once e.g. a stable Debian kernel has
similar requirements, I guess the same would apply there. I am not sure
upstream kernel development on Debian stable would be enough of an
argument to update it (or provide similar packages), but I am not a
member of the teams that would make that decision.

we currently don't provide multiple versions in parallel (like GCC or
LLVM though) besides this special affordance for browsers. I am not sure
this would be a good idea either given rustc's release cadence ;)

as discussed off-list, -backports might be a better place for providing
more recent toolchain packages on Debian stable, and independent from
this thread, I have pondered providing them there in the past already.
backports would only ship one version as well though, and at most the
one in testing (so it would also be affected by the freeze period, just
like unstable and testing).

> > https://tracker.debian.org/pkg/rust-cbindgen-web
> 
> We may use `cbindgen` too in the future, but not currently.

it's used by firefox :)

> Is something like `bindgen-web` also available for stable?

not yet, but could conceivably be provided once/iff there is a need (see
above).

Re: [PATCH 13/13] docs: rust: quick-start: add section on Linux distributions

[Miguel Ojeda]

On Fri, Jul 5, 2024 at 3:09 PM Fabian Grünbichler
<debian@fabian.gruenbichler.email> wrote:
>
> right now it is updated whenever its rdeps (firefox and chromium in
> stable) need newer versions. once e.g. a stable Debian kernel has
> similar requirements, I guess the same would apply there. I am not sure
> upstream kernel development on Debian stable would be enough of an
> argument to update it (or provide similar packages), but I am not a
> member of the teams that would make that decision.

That is reasonable.

> as discussed off-list, -backports might be a better place for providing
> more recent toolchain packages on Debian stable, and independent from
> this thread, I have pondered providing them there in the past already.
> backports would only ship one version as well though, and at most the
> one in testing (so it would also be affected by the freeze period, just
> like unstable and testing).

I imagine that could be useful for some (kernel or not) developers on
stable, even with the freeze period.

Thanks!

Cheers,
Miguel

Re: [PATCH 13/13] docs: rust: quick-start: add section on Linux distributions

[Miguel Ojeda]

On Fri, Jul 5, 2024 at 8:19 AM Andrea Righi <righi.andrea@gmail.com> wrote:
>
> This implicitly covers Ubuntu, since packages are sync'ed with Debian.

Do you mean the names (i.e. command) is the same, or that the newer
versions from e.g. Sid can be used in Ubuntu? If the latter, that
would be definitely worth adding, yeah -- is that supported / expected
to work?

> In addition to that Ubuntu also provides versioned packages (such as
> rustc-1.74, bindgen-0.65, etc.), so in case of special requirements
> (e.g., older kernels) users should be able to install the required
> version(s) using the packages provided by the distro.
>
> Maybe it's worth mentioning as a little note, so that users are aware of
> these extra packages.

I thought about adding a section for Ubuntu to mention those -- so far
I only added the distributions/commands that were likely to work with
the versions supported by the kernel, with the idea of expand later as
time passes. So I didn't add the versioned ones since the latest is
1.76, so it wouldn't work for the current kernel.

But it may be useful to state it nevertheless, since some people may
only look at the latest docs. (Or perhaps Ubuntu can add Rust 1.79? :)

Thanks!

Cheers,
Miguel

Re: [PATCH 13/13] docs: rust: quick-start: add section on Linux distributions

[Andrea Righi]

On Fri, Jul 05, 2024 at 12:50:35PM +0200, Miguel Ojeda wrote:
> On Fri, Jul 5, 2024 at 8:19 AM Andrea Righi <righi.andrea@gmail.com> wrote:
> >
> > This implicitly covers Ubuntu, since packages are sync'ed with Debian.
> 
> Do you mean the names (i.e. command) is the same, or that the newer
> versions from e.g. Sid can be used in Ubuntu? If the latter, that
> would be definitely worth adding, yeah -- is that supported / expected
> to work?

Command and package names are the same. We may also have different
(newer) versions than Sid, but this is up to foundations team.

Zixing, what do you think?

> 
> > In addition to that Ubuntu also provides versioned packages (such as
> > rustc-1.74, bindgen-0.65, etc.), so in case of special requirements
> > (e.g., older kernels) users should be able to install the required
> > version(s) using the packages provided by the distro.
> >
> > Maybe it's worth mentioning as a little note, so that users are aware of
> > these extra packages.
> 
> I thought about adding a section for Ubuntu to mention those -- so far
> I only added the distributions/commands that were likely to work with
> the versions supported by the kernel, with the idea of expand later as
> time passes. So I didn't add the versioned ones since the latest is
> 1.76, so it wouldn't work for the current kernel.
> 
> But it may be useful to state it nevertheless, since some people may
> only look at the latest docs. (Or perhaps Ubuntu can add Rust 1.79? :)

Actually, considering that this doc will go in newer kernels, probably
it's not worth to mention the *old* packages.

About Rust 1.79, calling out Zixing again... :) He may have newer Rust
packages in his ppa at some point, but I don't know how much we can
consider that ppa "official".

-Andrea

Re: [PATCH 00/13] Support several Rust toolchain versions

[Benno Lossin]

On 01.07.24 20:36, Miguel Ojeda wrote:
> Hi all,
> 
> It is time to start supporting several Rust toolchain versions and thus
> establish a minimum Rust compiler and `bindgen` version.
> 
> For the Rust compiler, we will start with a window of two stable
> releases, and widen it over time. This series keeps the minimum where
> it is (1.78.0), but 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. A documentation adds the instructions for each of them.
> 
> In addition, Rust for Linux is now being built-tested in Rust's
> pre-merge CI. 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.
> 
> Similarly, we kept the minimum as it is for `bindgen`. `bindgen` is also
> adding the kernel to its CI -- thanks!
> 
> Cheers,
> Miguel
> 
> 
> Miguel Ojeda (13):
>   rust: macros: indent list item in `paste!`'s docs
>   rust: init: simplify from `map_err` to `inspect_err`
>   rust: allow `dead_code` for never constructed bindings
>   rust: relax most deny-level lints to warnings
>   rust: simplify Clippy warning flags set
>   rust: start supporting several compiler versions
>   rust: warn about `bindgen` versions 0.66.0 and 0.66.1
>   rust: work around `bindgen` 0.69.0 issue
>   rust: avoid assuming a particular `bindgen` build
>   rust: start supporting several `bindgen` versions
>   kbuild: rust: add `rustc-version` support
>   rust: support the new `-Zub-checks` flag
>   docs: rust: quick-start: add section on Linux distributions
> 
>  Documentation/process/changes.rst  |   9 +--
>  Documentation/rust/quick-start.rst | 118 +++++++++++++++++++++++------
>  Makefile                           |  29 +++----
>  init/Kconfig                       |  11 ++-
>  lib/Kconfig.debug                  |  18 +++++
>  rust/Makefile                      |   4 +-
>  rust/bindings/lib.rs               |   1 +
>  rust/kernel/init.rs                |  12 +--
>  rust/macros/lib.rs                 |   2 +-
>  rust/uapi/lib.rs                   |   1 +
>  scripts/Kconfig.include            |   6 ++
>  scripts/Makefile.compiler          |   4 +
>  scripts/rust_is_available.sh       |  20 ++---
>  scripts/rust_is_available_test.py  |  40 +++++-----
>  scripts/rustc-version.sh           |  52 +++++++++++++
>  15 files changed, 238 insertions(+), 89 deletions(-)
>  create mode 100755 scripts/rustc-version.sh
> 
> 
> base-commit: f2661062f16b2de5d7b6a5c42a9a5c96326b8454
> --
> 2.45.2

I applied the series and successfully ran the kunit tests on nixos.
I tried the following rust versions via fenix:
- rustc 1.78.0 (9b00956e5 2024-04-29)
- rustc 1.79.0 (129f3b996 2024-06-10)
- 1.80.0-beta.4 (64a1fe671 2024-06-21)
- 1.81.0-nightly (6868c831a 2024-06-30)

My bindgen version is 0.69.4.

Everything worked as expected :)

Tested-by: Benno Lossin <benno.lossin@proton.me>

---
Cheers,
Benno

Re: [PATCH 00/13] Support several Rust toolchain versions

[Miguel Ojeda]

On Tue, Jul 2, 2024 at 8:25 AM Benno Lossin <benno.lossin@proton.me> wrote:
>
> I applied the series and successfully ran the kunit tests on nixos.
> I tried the following rust versions via fenix:
> - rustc 1.78.0 (9b00956e5 2024-04-29)
> - rustc 1.79.0 (129f3b996 2024-06-10)
> - 1.80.0-beta.4 (64a1fe671 2024-06-21)
> - 1.81.0-nightly (6868c831a 2024-06-30)
>
> My bindgen version is 0.69.4.
>
> Everything worked as expected :)

Thanks Benno! I tried nixpkgs' toolchain for the examples in the docs
patch, but not fenix's ones, so it's good to know those work as well. :)

Cheers,
Miguel