linux-kernel - Re: [PATCH] rust: add C FFI types to the prelude

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAH5fLgiF0kZdOYaQi18_LTNx6Onq-5PBomA=bwS0m0z+C0wtvg@mail.gmail.com>
Date: Mon, 14 Apr 2025 10:46:46 +0200
From: Alice Ryhl <aliceryhl@...gle.com>
To: Miguel Ojeda <ojeda@...nel.org>
Cc: Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>, 
	Gary Guo <gary@...yguo.net>, Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...nel.org>, 
	Trevor Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org, patches@...ts.linux.dev
Subject: Re: [PATCH] rust: add C FFI types to the prelude

On Sun, Apr 13, 2025 at 2:57 AM Miguel Ojeda <ojeda@...nel.org> wrote:
>
> 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/
> Signed-off-by: Miguel Ojeda <ojeda@...nel.org>

Yes please!

>  Documentation/rust/coding-guidelines.rst | 17 +++++++++++++++++
>  rust/kernel/prelude.rs                   |  5 +++++
>  2 files changed, 22 insertions(+)
>
> diff --git a/Documentation/rust/coding-guidelines.rst b/Documentation/rust/coding-guidelines.rst
> index 27f2a7bb5a4a..d0bf0b3a058a 100644
> --- a/Documentation/rust/coding-guidelines.rst
> +++ b/Documentation/rust/coding-guidelines.rst
> @@ -191,6 +191,23 @@ or:
>         /// [`struct mutex`]: srctree/include/linux/mutex.h
>
>
> +C FFI types
> +-----------
> +
> +Rust kernel code does not use the C FFI types (such as ``c_char``) from
> +``core::ffi::*``. Instead, a custom mapping that matches properly the C types
> +used in the kernel is provided in the prelude, i.e. ``kernel::prelude::*``.
> +
> +These types (aliases) should generally be referred directly by their identifier,
> +i.e. as a single segment path. For instance:
> +
> +.. code-block:: rust
> +
> +       fn f(p: *const c_char) -> c_int {
> +           // ...
> +       }

I wonder if it would make more sense to rephrase this section to first
say that rfl has type aliases for the C integer types called c_int and
so on, then mention that they are available in the prelude, and then
at the end of the section have a note that we don't use the type
aliases from core::ffi. I think focusing on how to use C integer
types, rather than technical details about how they are defined, is
more relevant for a reader who is just looking for coding guidelines.

Alice