From: "Danilo Krummrich" <dakr@kernel.org>
To: "Alice Ryhl" <aliceryhl@google.com>
Cc: <gregkh@linuxfoundation.org>, <rafael@kernel.org>,
<acourbot@nvidia.com>, <david.m.ertman@intel.com>,
<ira.weiny@intel.com>, <leon@kernel.org>, <ojeda@kernel.org>,
<boqun@kernel.org>, <gary@garyguo.net>,
<bjorn3_gh@protonmail.com>, <lossin@kernel.org>,
<a.hindborg@kernel.org>, <tmgross@umich.edu>,
<driver-core@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
<nova-gpu@lists.linux.dev>, <dri-devel@lists.freedesktop.org>,
<rust-for-linux@vger.kernel.org>
Subject: Re: [PATCH 1/2] rust: auxiliary: add registration data to auxiliary devices
Date: Thu, 30 Apr 2026 16:19:10 +0200 [thread overview]
Message-ID: <DI6JZKW4N7VD.3B3233F8PNOMU@kernel.org> (raw)
In-Reply-To: <afMaAfcxpDR3xIE1@google.com>
On Thu Apr 30, 2026 at 10:59 AM CEST, Alice Ryhl wrote:
> Is this really Rust-specific? Would you not want C drivers with the same
> pattern to do the same thing?
Unlike in C, it has the effect that it allows us to let the compiler ensure that
the initilization order in probe() is correct.
The only advantage I see in C is that it provides a dedicated place for drivers
to differentiate specific private data for when a driver registers multiple
auxiliary devices per instance.
>> + // SAFETY: `ptr` is non-null and was set via `into_foreign()` in `Registration::new()`;
>> + // `RegistrationData` is `#[repr(C)]` with `type_id` at offset 0, so reading a `TypeId`
>> + // at the start of the allocation is valid regardless of `T`.
>> + let type_id = unsafe { ptr.cast::<TypeId>().read() };
>> + if type_id != TypeId::of::<T>() {
>> + return Err(EINVAL);
>> + }
>
> Right, okay, so if you put C stuff there, we need the layout to be
> compatible with Rust type ids.
Correct.
> Still, we could have Rust expose a couple methods to allow C code to use
> the same field with a null type id.
I think there are multiple options, e.g. two registration data pointers, one
common pointer and a boolean, one common pointer, plus a type id pointer, etc.
> But I guess this is all future work.
Yes, I rather do that once we actually need it.
>> + let data = KBox::pin_init::<Error>(
>> + try_pin_init!(RegistrationData {
>> + type_id: TypeId::of::<T>(),
>> + data <- data,
>> + }),
>> + GFP_KERNEL,
>> + )?;
>> +
>> + let boxed = KBox::new(Opaque::<bindings::auxiliary_device>::zeroed(), GFP_KERNEL)?;
>
> Use __GFP_ZERO here instead?
This is just moving existing code, but I guess we could add something like:
pub fn zeroed(flags: Flags) -> Result<Self, AllocError>
where
T: Zeroable,
{
// SAFETY: `__GFP_ZERO` guarantees the memory is zeroed, and `T: Zeroable` guarantees
// that all-zeroes is a valid bit pattern for `T`.
Ok(unsafe { Self::new_uninit(flags | __GFP_ZERO)?.assume_init() })
}
>> + // SAFETY:
>> + // - `adev` is guaranteed to be a valid pointer to a `struct auxiliary_device`, which
>> + // has been initialized,
>> + // - `modname.as_char_ptr()` is a NULL terminated string.
>> + let ret = unsafe { bindings::__auxiliary_device_add(adev, modname.as_char_ptr()) };
>> + if ret != 0 {
>> + // SAFETY: `registration_data` was set above via `into_foreign()`.
>> + let _ = unsafe {
>> + Pin::<KBox<RegistrationData<T>>>::from_foreign((*adev).registration_data_rust)
>> + };
>
> Nit: Please use `drop(unsafe { ... })` to explicitly drop.
Same here, just moving existing code, but I think it's fine to change while at
it.
next prev parent reply other threads:[~2026-04-30 14:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-27 22:09 [PATCH 0/2] rust: auxiliary: replace drvdata() with registration data Danilo Krummrich
2026-04-27 22:09 ` [PATCH 1/2] rust: auxiliary: add registration data to auxiliary devices Danilo Krummrich
2026-04-28 10:18 ` Danilo Krummrich
2026-04-29 11:21 ` Alexandre Courbot
2026-04-29 13:58 ` Danilo Krummrich
2026-04-30 8:59 ` Alice Ryhl
2026-04-30 14:19 ` Danilo Krummrich [this message]
2026-04-30 14:31 ` Gary Guo
2026-04-30 15:08 ` Gary Guo
2026-04-30 16:05 ` Danilo Krummrich
2026-04-27 22:09 ` [PATCH 2/2] rust: driver core: remove drvdata() and driver_type Danilo Krummrich
2026-04-30 9:00 ` Alice Ryhl
2026-04-27 22:14 ` [PATCH 0/2] rust: auxiliary: replace drvdata() with registration data Danilo Krummrich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DI6JZKW4N7VD.3B3233F8PNOMU@kernel.org \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=david.m.ertman@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=driver-core@lists.linux.dev \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=ira.weiny@intel.com \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=nova-gpu@lists.linux.dev \
--cc=ojeda@kernel.org \
--cc=rafael@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox