Re: [PATCH] rust: types: add Opaque::from_raw

[Danilo Krummrich <dakr@kernel.org>]

On Wed, Jun 18, 2025 at 07:59:20AM +0000, Alice Ryhl wrote:
> On Tue, Jun 17, 2025 at 03:54:19PM +0200, Danilo Krummrich wrote:
> > On Tue, Jun 17, 2025 at 01:36:47PM +0000, Alice Ryhl wrote:
> > > Since commit b20fbbc08a36 ("rust: check type of `$ptr` in
> > > `container_of!`") we have enforced that the field pointer passed to
> > > container_of! must match the declared field. This caused mismatches when
> > > using a pointer to bindings::x for fields of type Opaque<bindings::x>.
> > > 
> > > This situation encourages the user to simply pass field.cast() to the
> > > container_of! macro, but this is not great because you might
> > > accidentally pass a *mut bindings::y when the field type is
> > > Opaque<bindings::x>, which would be wrong.
> > > 
> > > To help catch this kind of mistake, add a new Opaque::from_raw that
> > > wraps a raw pointer in Opaque without changing the inner type.
> > 
> > The patch does more than that, it also adds a hint to container_of!() and fixes
> > up two occurences. I feel like we should split it up.
> 
> I think they go together pretty naturally, but I can split it if you
> insist.

Nah, it's also fine for me to keep it as is, but in that case we should also
mention the other changes in the commit message.

> > > +    /// The opposite operation of [`Opaque::raw_get`].
> > > +    pub const fn from_raw(this: *const T) -> *const Self {
> > 
> > Do we want to name this from_raw()? Usually from_raw() methods return either
> > Self or &'a Self.
> > 
> > Maybe something like cast_from() and rename raw_get() to cast_into()? I think
> > the latter may be confusing anyways, since it sounds like it would do somthing
> > with reference counting.
> 
> The name raw_get() mirrors the stdlib function UnsafeCell::raw_get().
> The stdlib uses this naming because in Rust the word "get" normally has
> nothing to do with reference counting - outside of the kernel, we use
> "clone" for incrementing refcounts and nobody would ever call it "get".

Yeah, I'm aware. The main reason I proposed cast_into() is that it would fit
much better with the newly introduced cast_from() (in case we go with that
name).

I'm happy with other proposals too, I just think that from_raw() would be a bit
inconsistent with how we use this name otherwise.

> That said, it may still be worth to rename the method. Thoughts?

I think it'd be good if it aligns naming wise with its counter part added in
this patch and I don't see this happening with raw_get(). :-)