<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/rust/kernel/prelude.rs, branch v6.18.21</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>rust: prelude: re-export `core::mem::{align,size}_of{,_val}`</title>
<updated>2025-09-07T22:11:19+00:00</updated>
<author>
<name>Miguel Ojeda</name>
<email>ojeda@kernel.org</email>
</author>
<published>2025-08-01T16:17:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=72b04a8af7fb11e0f12e52985543d7e699fd4406'/>
<id>72b04a8af7fb11e0f12e52985543d7e699fd4406</id>
<content type='text'>
Rust 1.80.0 added:

    align_of
    align_of_val
    size_of
    size_of_val

from `core::mem` to the prelude [1].

For similar reasons, and to minimize potential confusion when code may
work in later versions but not in our current minimum, add it to our
prelude too.

Link: https://github.com/rust-lang/rust/pull/123168 [1]
Link: https://lore.kernel.org/rust-for-linux/CANiq72kOLYR2A95o0ji2mDmEqOKh9e9_60zZKmgF=vZmsW6DRg@mail.gmail.com/ [2]
Reviewed-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Reviewed-by: Alexandre Courbot &lt;acourbot@nvidia.com&gt;
Reviewed-by: Andreas Hindborg &lt;a.hindborg@kernel.org&gt;
Reviewed-by: Daniel Almeida &lt;daniel.almeida@collabora.com&gt;
Reviewed-by: Benno Lossin &lt;lossin@kernel.org&gt;
Signed-off-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Rust 1.80.0 added:

    align_of
    align_of_val
    size_of
    size_of_val

from `core::mem` to the prelude [1].

For similar reasons, and to minimize potential confusion when code may
work in later versions but not in our current minimum, add it to our
prelude too.

Link: https://github.com/rust-lang/rust/pull/123168 [1]
Link: https://lore.kernel.org/rust-for-linux/CANiq72kOLYR2A95o0ji2mDmEqOKh9e9_60zZKmgF=vZmsW6DRg@mail.gmail.com/ [2]
Reviewed-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Reviewed-by: Alexandre Courbot &lt;acourbot@nvidia.com&gt;
Reviewed-by: Andreas Hindborg &lt;a.hindborg@kernel.org&gt;
Reviewed-by: Daniel Almeida &lt;daniel.almeida@collabora.com&gt;
Reviewed-by: Benno Lossin &lt;lossin@kernel.org&gt;
Signed-off-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rust: kernel: remove `fmt!`, fix clippy::uninlined-format-args</title>
<updated>2025-07-20T23:15:51+00:00</updated>
<author>
<name>Tamir Duberstein</name>
<email>tamird@gmail.com</email>
</author>
<published>2025-07-04T20:14:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=f411b7eddde8b780a61dadea0916480f5c9edf5a'/>
<id>f411b7eddde8b780a61dadea0916480f5c9edf5a</id>
<content type='text'>
Rather than export a macro that delegates to `core::format_args`, simply
re-export `core::format_args` as `fmt` from the prelude. This exposes
clippy warnings which were previously obscured by this macro, such as:

    warning: variables can be used directly in the `format!` string
      --&gt; ../drivers/cpufreq/rcpufreq_dt.rs:21:43
       |
    21 |     let prop_name = CString::try_from_fmt(fmt!("{}-supply", name)).ok()?;
       |                                           ^^^^^^^^^^^^^^^^^^^^^^^
       |
       = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args
       = note: `-W clippy::uninlined-format-args` implied by `-W clippy::all`
       = help: to override `-W clippy::all` add `#[allow(clippy::uninlined_format_args)]`
    help: change this to
       |
    21 -     let prop_name = CString::try_from_fmt(fmt!("{}-supply", name)).ok()?;
    21 +     let prop_name = CString::try_from_fmt(fmt!("{name}-supply")).ok()?;
       |

Thus fix them in the same commit. This could possibly be fixed in two
stages, but the diff is small enough (outside of kernel/str.rs) that I
hope it can be taken in a single commit.

Signed-off-by: Tamir Duberstein &lt;tamird@gmail.com&gt;
Reviewed-by: Benno Lossin &lt;lossin@kernel.org&gt;
Reviewed-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Acked-by: Danilo Krummrich &lt;dakr@kernel.org&gt;
Link: https://lore.kernel.org/r/20250704-core-cstr-prepare-v1-1-a91524037783@gmail.com
Signed-off-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Rather than export a macro that delegates to `core::format_args`, simply
re-export `core::format_args` as `fmt` from the prelude. This exposes
clippy warnings which were previously obscured by this macro, such as:

    warning: variables can be used directly in the `format!` string
      --&gt; ../drivers/cpufreq/rcpufreq_dt.rs:21:43
       |
    21 |     let prop_name = CString::try_from_fmt(fmt!("{}-supply", name)).ok()?;
       |                                           ^^^^^^^^^^^^^^^^^^^^^^^
       |
       = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args
       = note: `-W clippy::uninlined-format-args` implied by `-W clippy::all`
       = help: to override `-W clippy::all` add `#[allow(clippy::uninlined_format_args)]`
    help: change this to
       |
    21 -     let prop_name = CString::try_from_fmt(fmt!("{}-supply", name)).ok()?;
    21 +     let prop_name = CString::try_from_fmt(fmt!("{name}-supply")).ok()?;
       |

Thus fix them in the same commit. This could possibly be fixed in two
stages, but the diff is small enough (outside of kernel/str.rs) that I
hope it can be taken in a single commit.

Signed-off-by: Tamir Duberstein &lt;tamird@gmail.com&gt;
Reviewed-by: Benno Lossin &lt;lossin@kernel.org&gt;
Reviewed-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Acked-by: Danilo Krummrich &lt;dakr@kernel.org&gt;
Link: https://lore.kernel.org/r/20250704-core-cstr-prepare-v1-1-a91524037783@gmail.com
Signed-off-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rust: uaccess: use newtype for user pointers</title>
<updated>2025-07-14T21:52:45+00:00</updated>
<author>
<name>Alice Ryhl</name>
<email>aliceryhl@google.com</email>
</author>
<published>2025-06-16T13:45:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=60ecf796cdc8638c570a4ad06bae6a0d48a8986d'/>
<id>60ecf796cdc8638c570a4ad06bae6a0d48a8986d</id>
<content type='text'>
Currently, Rust code uses a typedef for unsigned long to represent
userspace addresses. This is unfortunate because it means that userspace
addresses could accidentally be mixed up with other integers. To
alleviate that, we introduce a new UserPtr struct that wraps a raw
pointer to represent a userspace address. By using a struct, type
checking enforces that userspace addresses cannot be mixed up with
anything else.

This is similar to the __user annotation in C that detects cases where
user pointers are mixed with non-user pointers.

Note that unlike __user pointers in C, this type is just a pointer
without a target type. This means that it can't detect cases such as
mixing up which struct this user pointer references. However, that is
okay due to the way this is intended to be used - generally, you create
a UserPtr in your ioctl callback from the provided usize *before*
dispatching on which ioctl is in use, and then after dispatching on the
ioctl you pass the UserPtr into a UserSliceReader or UserSliceWriter;
selecting the target type does not happen until you have obtained the
UserSliceReader/Writer.

The UserPtr type is not marked with #[derive(Debug)], which means that
it's not possible to print values of this type. This avoids ASLR
leakage.

The type is added to the prelude as it is a fairly fundamental type
similar to c_int. The wrapping_add() method is renamed to
wrapping_byte_add() for consistency with the method name found on raw
pointers.

Reviewed-by: Benno Lossin &lt;lossin@kernel.org&gt;
Reviewed-by: Danilo Krummrich &lt;dakr@kernel.org&gt;
Reviewed-by: Christian Schrefl &lt;chrisi.schrefl@gmail.com&gt;
Reviewed-by: Boqun Feng &lt;boqun.feng@gmail.com&gt;
Reviewed-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Link: https://lore.kernel.org/r/20250616-userptr-newtype-v3-1-5ff7b2d18d9e@google.com
[ Reworded title. - Miguel ]
Signed-off-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently, Rust code uses a typedef for unsigned long to represent
userspace addresses. This is unfortunate because it means that userspace
addresses could accidentally be mixed up with other integers. To
alleviate that, we introduce a new UserPtr struct that wraps a raw
pointer to represent a userspace address. By using a struct, type
checking enforces that userspace addresses cannot be mixed up with
anything else.

This is similar to the __user annotation in C that detects cases where
user pointers are mixed with non-user pointers.

Note that unlike __user pointers in C, this type is just a pointer
without a target type. This means that it can't detect cases such as
mixing up which struct this user pointer references. However, that is
okay due to the way this is intended to be used - generally, you create
a UserPtr in your ioctl callback from the provided usize *before*
dispatching on which ioctl is in use, and then after dispatching on the
ioctl you pass the UserPtr into a UserSliceReader or UserSliceWriter;
selecting the target type does not happen until you have obtained the
UserSliceReader/Writer.

The UserPtr type is not marked with #[derive(Debug)], which means that
it's not possible to print values of this type. This avoids ASLR
leakage.

The type is added to the prelude as it is a fairly fundamental type
similar to c_int. The wrapping_add() method is renamed to
wrapping_byte_add() for consistency with the method name found on raw
pointers.

Reviewed-by: Benno Lossin &lt;lossin@kernel.org&gt;
Reviewed-by: Danilo Krummrich &lt;dakr@kernel.org&gt;
Reviewed-by: Christian Schrefl &lt;chrisi.schrefl@gmail.com&gt;
Reviewed-by: Boqun Feng &lt;boqun.feng@gmail.com&gt;
Reviewed-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Link: https://lore.kernel.org/r/20250616-userptr-newtype-v3-1-5ff7b2d18d9e@google.com
[ Reworded title. - Miguel ]
Signed-off-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rust: add `kunit_tests` to the prelude</title>
<updated>2025-05-27T18:09:59+00:00</updated>
<author>
<name>Miguel Ojeda</name>
<email>ojeda@kernel.org</email>
</author>
<published>2025-05-02T21:51:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=897d1df6532f05814acd364af9055cd6628fd1b3'/>
<id>897d1df6532f05814acd364af9055cd6628fd1b3</id>
<content type='text'>
It is convenient to have certain things in the `kernel` prelude, and
means kernel developers will find it even easier to start writing tests.

And, anyway, nobody should need to use this identifier for anything else.

Thus add it to the prelude.

Reviewed-by: David Gow &lt;davidgow@google.com&gt;
Acked-by: Danilo Krummrich &lt;dakr@kernel.org&gt;
Link: https://lore.kernel.org/r/20250502215133.1923676-4-ojeda@kernel.org
Signed-off-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It is convenient to have certain things in the `kernel` prelude, and
means kernel developers will find it even easier to start writing tests.

And, anyway, nobody should need to use this identifier for anything else.

Thus add it to the prelude.

Reviewed-by: David Gow &lt;davidgow@google.com&gt;
Acked-by: Danilo Krummrich &lt;dakr@kernel.org&gt;
Link: https://lore.kernel.org/r/20250502215133.1923676-4-ojeda@kernel.org
Signed-off-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rust: add C FFI types to the prelude</title>
<updated>2025-05-23T14:31:43+00:00</updated>
<author>
<name>Miguel Ojeda</name>
<email>ojeda@kernel.org</email>
</author>
<published>2025-04-13T00:56:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=3d5bef5d47c371e17041cd6c84e9c08e54ea9e63'/>
<id>3d5bef5d47c371e17041cd6c84e9c08e54ea9e63</id>
<content type='text'>
Rust kernel code is supposed to use the custom mapping of C FFI types,
i.e. those from the `ffi` crate, rather than the ones coming from `core`.

Thus, to minimize mistakes and to simplify the code everywhere, just
provide them in the `kernel` prelude and ask in the Coding Guidelines
to use them directly, i.e. as a single segment path.

After this lands, we can start cleaning up the existing users.

Ideally, we would use something like Clippy's `disallowed-types` to
prevent the use of the `core` ones, but that one sees through aliases.

Link: https://lore.kernel.org/rust-for-linux/CANiq72kc4gzfieD-FjuWfELRDXXD2vLgPv4wqk3nt4pjdPQ=qg@mail.gmail.com/
Reviewed-by: Danilo Krummrich &lt;dakr@kernel.org&gt;
Reviewed-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Link: https://lore.kernel.org/r/20250413005650.1745894-1-ojeda@kernel.org
[ Reworded content of the documentation to focus on how to use the
  aliases first. - Miguel ]
Signed-off-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Rust kernel code is supposed to use the custom mapping of C FFI types,
i.e. those from the `ffi` crate, rather than the ones coming from `core`.

Thus, to minimize mistakes and to simplify the code everywhere, just
provide them in the `kernel` prelude and ask in the Coding Guidelines
to use them directly, i.e. as a single segment path.

After this lands, we can start cleaning up the existing users.

Ideally, we would use something like Clippy's `disallowed-types` to
prevent the use of the `core` ones, but that one sees through aliases.

Link: https://lore.kernel.org/rust-for-linux/CANiq72kc4gzfieD-FjuWfELRDXXD2vLgPv4wqk3nt4pjdPQ=qg@mail.gmail.com/
Reviewed-by: Danilo Krummrich &lt;dakr@kernel.org&gt;
Reviewed-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Link: https://lore.kernel.org/r/20250413005650.1745894-1-ojeda@kernel.org
[ Reworded content of the documentation to focus on how to use the
  aliases first. - Miguel ]
Signed-off-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rust: make pin-init its own crate</title>
<updated>2025-03-16T20:59:19+00:00</updated>
<author>
<name>Benno Lossin</name>
<email>benno.lossin@proton.me</email>
</author>
<published>2025-03-08T11:05:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=dbd5058ba60c3499b24a7133a4e2e24dba6ea77b'/>
<id>dbd5058ba60c3499b24a7133a4e2e24dba6ea77b</id>
<content type='text'>
Rename relative paths inside of the crate to still refer to the same
items, also rename paths inside of the kernel crate and adjust the build
system to build the crate.

[ Remove the `expect` (and thus the `lint_reasons` feature) since
  the tree now uses `quote!` from `rust/macros/export.rs`. Remove the
  `TokenStream` import removal, since it is now used as well.

  In addition, temporarily (i.e. just for this commit) use an `--extern
  force:alloc` to prevent an unknown `new_uninit` error in the `rustdoc`
  target. For context, please see a similar case in:

      https://lore.kernel.org/lkml/20240422090644.525520-1-ojeda@kernel.org/

  And adjusted the message above. - Miguel ]

Signed-off-by: Benno Lossin &lt;benno.lossin@proton.me&gt;
Reviewed-by: Fiona Behrens &lt;me@kloenk.dev&gt;
Tested-by: Andreas Hindborg &lt;a.hindborg@kernel.org&gt;
Link: https://lore.kernel.org/r/20250308110339.2997091-16-benno.lossin@proton.me
Signed-off-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Rename relative paths inside of the crate to still refer to the same
items, also rename paths inside of the kernel crate and adjust the build
system to build the crate.

[ Remove the `expect` (and thus the `lint_reasons` feature) since
  the tree now uses `quote!` from `rust/macros/export.rs`. Remove the
  `TokenStream` import removal, since it is now used as well.

  In addition, temporarily (i.e. just for this commit) use an `--extern
  force:alloc` to prevent an unknown `new_uninit` error in the `rustdoc`
  target. For context, please see a similar case in:

      https://lore.kernel.org/lkml/20240422090644.525520-1-ojeda@kernel.org/

  And adjusted the message above. - Miguel ]

Signed-off-by: Benno Lossin &lt;benno.lossin@proton.me&gt;
Reviewed-by: Fiona Behrens &lt;me@kloenk.dev&gt;
Tested-by: Andreas Hindborg &lt;a.hindborg@kernel.org&gt;
Link: https://lore.kernel.org/r/20250308110339.2997091-16-benno.lossin@proton.me
Signed-off-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rust: pin-init: move `InPlaceInit` and impls of `InPlaceWrite` into the kernel crate</title>
<updated>2025-03-16T20:59:18+00:00</updated>
<author>
<name>Benno Lossin</name>
<email>benno.lossin@proton.me</email>
</author>
<published>2025-03-08T11:04:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=114ca41fe7922ce85fcac30fa2b06b42b4956520'/>
<id>114ca41fe7922ce85fcac30fa2b06b42b4956520</id>
<content type='text'>
In order to make pin-init a standalone crate, move kernel-specific code
directly into the kernel crate. This includes the `InPlaceInit&lt;T&gt;`
trait, its implementations and the implementations of `InPlaceWrite` for
`Arc` and `UniqueArc`. All of these use the kernel's error type which
will become unavailable in pin-init.

Signed-off-by: Benno Lossin &lt;benno.lossin@proton.me&gt;
Reviewed-by: Fiona Behrens &lt;me@kloenk.dev&gt;
Tested-by: Andreas Hindborg &lt;a.hindborg@kernel.org&gt;
Link: https://lore.kernel.org/r/20250308110339.2997091-9-benno.lossin@proton.me
Signed-off-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In order to make pin-init a standalone crate, move kernel-specific code
directly into the kernel crate. This includes the `InPlaceInit&lt;T&gt;`
trait, its implementations and the implementations of `InPlaceWrite` for
`Arc` and `UniqueArc`. All of these use the kernel's error type which
will become unavailable in pin-init.

Signed-off-by: Benno Lossin &lt;benno.lossin@proton.me&gt;
Reviewed-by: Fiona Behrens &lt;me@kloenk.dev&gt;
Tested-by: Andreas Hindborg &lt;a.hindborg@kernel.org&gt;
Link: https://lore.kernel.org/r/20250308110339.2997091-9-benno.lossin@proton.me
Signed-off-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rust: add #[export] macro</title>
<updated>2025-03-09T19:52:46+00:00</updated>
<author>
<name>Alice Ryhl</name>
<email>aliceryhl@google.com</email>
</author>
<published>2025-03-03T08:45:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=44e333fe464a253f703982f721c7155218f63d1f'/>
<id>44e333fe464a253f703982f721c7155218f63d1f</id>
<content type='text'>
Rust has two different tools for generating function declarations to
call across the FFI boundary:

* bindgen. Generates Rust declarations from a C header.
* cbindgen. Generates C headers from Rust declarations.

However, we only use bindgen in the kernel. This means that when C code
calls a Rust function by name, its signature must be duplicated in both
Rust code and a C header, and the signature needs to be kept in sync
manually.

Introducing cbindgen as a mandatory dependency to build the kernel would
be a rather complex and large change, so we do not consider that at this
time. Instead, to eliminate this manual checking, introduce a new macro
that verifies at compile time that the two function declarations use the
same signature. The idea is to run the C declaration through bindgen,
and then have rustc verify that the function pointers have the same
type.

The signature must still be written twice, but at least you can no
longer get it wrong. If the signatures don't match, you will get errors
that look like this:

error[E0308]: `if` and `else` have incompatible types
  --&gt; &lt;linux&gt;/rust/kernel/print.rs:22:22
   |
21 | #[export]
   | --------- expected because of this
22 | unsafe extern "C" fn rust_fmt_argument(
   |                      ^^^^^^^^^^^^^^^^^ expected `u8`, found `i8`
   |
   = note: expected fn item `unsafe extern "C" fn(*mut u8, *mut u8, *mut c_void) -&gt; *mut u8 {bindings::rust_fmt_argument}`
              found fn item `unsafe extern "C" fn(*mut i8, *mut i8, *const c_void) -&gt; *mut i8 {print::rust_fmt_argument}`

It is unfortunate that the error message starts out by saying "`if` and
`else` have incompatible types", but I believe the rest of the error
message is reasonably clear and not too confusing.

Reviewed-by: Tamir Duberstein &lt;tamird@gmail.com&gt;
Reviewed-by: Andreas Hindborg &lt;a.hindborg@kernel.org&gt;
Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Link: https://lore.kernel.org/r/20250303-export-macro-v3-3-41fbad85a27f@google.com
Signed-off-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Rust has two different tools for generating function declarations to
call across the FFI boundary:

* bindgen. Generates Rust declarations from a C header.
* cbindgen. Generates C headers from Rust declarations.

However, we only use bindgen in the kernel. This means that when C code
calls a Rust function by name, its signature must be duplicated in both
Rust code and a C header, and the signature needs to be kept in sync
manually.

Introducing cbindgen as a mandatory dependency to build the kernel would
be a rather complex and large change, so we do not consider that at this
time. Instead, to eliminate this manual checking, introduce a new macro
that verifies at compile time that the two function declarations use the
same signature. The idea is to run the C declaration through bindgen,
and then have rustc verify that the function pointers have the same
type.

The signature must still be written twice, but at least you can no
longer get it wrong. If the signatures don't match, you will get errors
that look like this:

error[E0308]: `if` and `else` have incompatible types
  --&gt; &lt;linux&gt;/rust/kernel/print.rs:22:22
   |
21 | #[export]
   | --------- expected because of this
22 | unsafe extern "C" fn rust_fmt_argument(
   |                      ^^^^^^^^^^^^^^^^^ expected `u8`, found `i8`
   |
   = note: expected fn item `unsafe extern "C" fn(*mut u8, *mut u8, *mut c_void) -&gt; *mut u8 {bindings::rust_fmt_argument}`
              found fn item `unsafe extern "C" fn(*mut i8, *mut i8, *const c_void) -&gt; *mut i8 {print::rust_fmt_argument}`

It is unfortunate that the error message starts out by saying "`if` and
`else` have incompatible types", but I believe the rest of the error
message is reasonably clear and not too confusing.

Reviewed-by: Tamir Duberstein &lt;tamird@gmail.com&gt;
Reviewed-by: Andreas Hindborg &lt;a.hindborg@kernel.org&gt;
Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Link: https://lore.kernel.org/r/20250303-export-macro-v3-3-41fbad85a27f@google.com
Signed-off-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rust: add `build_error!` to the prelude</title>
<updated>2025-01-09T23:19:09+00:00</updated>
<author>
<name>Miguel Ojeda</name>
<email>ojeda@kernel.org</email>
</author>
<published>2024-11-23T22:28:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=4401565fe92be6ee54a68ea58d80a4076007d5eb'/>
<id>4401565fe92be6ee54a68ea58d80a4076007d5eb</id>
<content type='text'>
The sibling `build_assert!` is already in the prelude, it makes sense
that a "core"/"language" facility like this is part of the prelude and
users should not be defining their own one (thus there should be no risk
of future name collisions and we would want to be aware of them anyway).

Thus add `build_error!` into the prelude.

Reviewed-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Link: https://lore.kernel.org/r/20241123222849.350287-3-ojeda@kernel.org
[ Applied the change to the new miscdevice cases. - Miguel ]
Signed-off-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The sibling `build_assert!` is already in the prelude, it makes sense
that a "core"/"language" facility like this is part of the prelude and
users should not be defining their own one (thus there should be no risk
of future name collisions and we would want to be aware of them anyway).

Thus add `build_error!` into the prelude.

Reviewed-by: Alice Ryhl &lt;aliceryhl@google.com&gt;
Link: https://lore.kernel.org/r/20241123222849.350287-3-ojeda@kernel.org
[ Applied the change to the new miscdevice cases. - Miguel ]
Signed-off-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'char-misc-6.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc</title>
<updated>2024-11-29T19:58:27+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2024-11-29T19:58:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=2eff01ee2881becc9daaa0d53477ec202136b1f4'/>
<id>2eff01ee2881becc9daaa0d53477ec202136b1f4</id>
<content type='text'>
Pull char/misc/IIO/whatever driver subsystem updates from Greg KH:
 "Here is the 'big and hairy' char/misc/iio and other small driver
  subsystem updates for 6.13-rc1.

  Loads of things in here, and even a fun merge conflict!

   - rust misc driver bindings and other rust changes to make misc
     drivers actually possible.

     I think this is the tipping point, expect to see way more rust
     drivers going forward now that these bindings are present. Next
     merge window hopefully we will have pci and platform drivers
     working, which will fully enable almost all driver subsystems to
     start accepting (or at least getting) rust drivers.

     This is the end result of a lot of work from a lot of people,
     congrats to all of them for getting this far, you've proved many of
     us wrong in the best way possible, working code :)

   - IIO driver updates, too many to list individually, that subsystem
     keeps growing and growing...

   - Interconnect driver updates

   - nvmem driver updates

   - pwm driver updates

   - platform_driver::remove() fixups, loads of them

   - counter driver updates

   - misc driver updates (keba?)

   - binder driver updates and fixes

   - loads of other small char/misc/etc driver updates and additions,
     full details in the shortlog.

  All of these have been in linux-next for a while, with no other
  reported issues other than that merge conflict"

* tag 'char-misc-6.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (401 commits)
  mei: vsc: Fix typo "maintstepping" -&gt; "mainstepping"
  firmware: Switch back to struct platform_driver::remove()
  misc: isl29020: Fix the wrong format specifier
  scripts/tags.sh: Don't tag usages of DEFINE_MUTEX
  fpga: Switch back to struct platform_driver::remove()
  mei: vsc: Improve error logging in vsc_identify_silicon()
  mei: vsc: Do not re-enable interrupt from vsc_tp_reset()
  dt-bindings: spmi: qcom,x1e80100-spmi-pmic-arb: Add SAR2130P compatible
  dt-bindings: spmi: spmi-mtk-pmif: Add compatible for MT8188
  spmi: pmic-arb: fix return path in for_each_available_child_of_node()
  iio: Move __private marking before struct element priv in struct iio_dev
  docs: iio: ad7380: add adaq4370-4 and adaq4380-4
  iio: adc: ad7380: add support for adaq4370-4 and adaq4380-4
  iio: adc: ad7380: use local dev variable to shorten long lines
  iio: adc: ad7380: fix oversampling formula
  dt-bindings: iio: adc: ad7380: add adaq4370-4 and adaq4380-4 compatible parts
  bus: mhi: host: pci_generic: Use pcim_iomap_region() to request and map MHI BAR
  bus: mhi: host: Switch trace_mhi_gen_tre fields to native endian
  misc: atmel-ssc: Use of_property_present() for non-boolean properties
  misc: keba: Add hardware dependency
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull char/misc/IIO/whatever driver subsystem updates from Greg KH:
 "Here is the 'big and hairy' char/misc/iio and other small driver
  subsystem updates for 6.13-rc1.

  Loads of things in here, and even a fun merge conflict!

   - rust misc driver bindings and other rust changes to make misc
     drivers actually possible.

     I think this is the tipping point, expect to see way more rust
     drivers going forward now that these bindings are present. Next
     merge window hopefully we will have pci and platform drivers
     working, which will fully enable almost all driver subsystems to
     start accepting (or at least getting) rust drivers.

     This is the end result of a lot of work from a lot of people,
     congrats to all of them for getting this far, you've proved many of
     us wrong in the best way possible, working code :)

   - IIO driver updates, too many to list individually, that subsystem
     keeps growing and growing...

   - Interconnect driver updates

   - nvmem driver updates

   - pwm driver updates

   - platform_driver::remove() fixups, loads of them

   - counter driver updates

   - misc driver updates (keba?)

   - binder driver updates and fixes

   - loads of other small char/misc/etc driver updates and additions,
     full details in the shortlog.

  All of these have been in linux-next for a while, with no other
  reported issues other than that merge conflict"

* tag 'char-misc-6.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (401 commits)
  mei: vsc: Fix typo "maintstepping" -&gt; "mainstepping"
  firmware: Switch back to struct platform_driver::remove()
  misc: isl29020: Fix the wrong format specifier
  scripts/tags.sh: Don't tag usages of DEFINE_MUTEX
  fpga: Switch back to struct platform_driver::remove()
  mei: vsc: Improve error logging in vsc_identify_silicon()
  mei: vsc: Do not re-enable interrupt from vsc_tp_reset()
  dt-bindings: spmi: qcom,x1e80100-spmi-pmic-arb: Add SAR2130P compatible
  dt-bindings: spmi: spmi-mtk-pmif: Add compatible for MT8188
  spmi: pmic-arb: fix return path in for_each_available_child_of_node()
  iio: Move __private marking before struct element priv in struct iio_dev
  docs: iio: ad7380: add adaq4370-4 and adaq4380-4
  iio: adc: ad7380: add support for adaq4370-4 and adaq4380-4
  iio: adc: ad7380: use local dev variable to shorten long lines
  iio: adc: ad7380: fix oversampling formula
  dt-bindings: iio: adc: ad7380: add adaq4370-4 and adaq4380-4 compatible parts
  bus: mhi: host: pci_generic: Use pcim_iomap_region() to request and map MHI BAR
  bus: mhi: host: Switch trace_mhi_gen_tre fields to native endian
  misc: atmel-ssc: Use of_property_present() for non-boolean properties
  misc: keba: Add hardware dependency
  ...
</pre>
</div>
</content>
</entry>
</feed>
