Re: [PATCH 1/2] rust: auxiliary: add registration data to auxiliary devices

[Danilo Krummrich]

On Wed Apr 29, 2026 at 1:21 PM CEST, Alexandre Courbot wrote:
> I'm wondering whether we could avoid introducing a Rust-only member
> here, either by just allowing the aux device private data to be used in
> C as well (which might be as simple as a rename, a couple helpers and a
> bit more documentation),

This is intentional; if this pointer would be shared we loose the guarantee that
the stored pointer is either NULL or of the following form.

	#[repr(C)]
	#[pin_data]
	struct RegistrationData<T> {
	    type_id: TypeId,
	    #[pin]
	    data: T,
	}

This is important, since otherwise we can't check the TypeId independent from T.
Of course, we could store the TypeId in a separate allocation and use this
instead, but then we'd also end up with a Rust specific pointer.

> or using a wrapper type specifically for Rust
> drivers:
>
> struct rust_auxiliary_device {
> 	struct auxiliary_device auxdev;
> 	void *registration_data;
> };
>
> Although I am not sure what the implications would be for e.g. a Rust
> auxiliary device spawned by a C driver? Is that even doable with the
> current code anyway?

You gave the answer yourself with this. :) If we'd "subclass", there'd be no way
to distinguish whether the struct auxiliary_device * passed by bus callbacks
stems from a C or from a Rust registration, i.e. we'd not know whether the
"upcast" is valid or not.