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 for Android: free password hash cracker in your pocket

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

Message-ID: <Z_z4eaYwADrHTVLW@cassiopeiae>
Date: Mon, 14 Apr 2025 13:58:49 +0200
From: Danilo Krummrich <dakr@...nel.org>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Miguel Ojeda <ojeda@...nel.org>, 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>, 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 Mon, Apr 14, 2025 at 10:46:46AM +0200, Alice Ryhl wrote:
> 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.

I think that's a good suggestion. With that,

	Reviewed-by: Danilo Krummrich <dakr@...nel.org>