Re: [PATCH v19 1/3] rust: types: add `ForeignOwnable::PointedTo`

[Andreas Hindborg <a.hindborg@kernel.org>]

"Alice Ryhl" <aliceryhl@google.com> writes:

> On Wed, Apr 30, 2025 at 8:57 PM Tamir Duberstein <tamird@gmail.com> wrote:
>>
>> On Wed, Apr 30, 2025 at 11:31 AM Gary Guo <gary@garyguo.net> wrote:
>> >
>> > On Wed, 23 Apr 2025 09:54:37 -0400
>> > Tamir Duberstein <tamird@gmail.com> wrote:
>> > > -impl<T: 'static, A> ForeignOwnable for Box<T, A>
>> > > +// SAFETY: The `into_foreign` function returns a pointer that is well-aligned.
>> > > +unsafe impl<T: 'static, A> ForeignOwnable for Box<T, A>
>> > >  where
>> > >      A: Allocator,
>> > >  {
>> > > +    type PointedTo = T;
>> >
>> > I don't think this is the correct solution for this. The returned
>> > pointer is supposed to opaque, and exposing this type may encourage
>> > this is to be wrongly used.
>>
>> Can you give an example?
>
> This came up when we discussed this patch in the meeting yesterday:
> https://lore.kernel.org/all/20250227-configfs-v5-1-c40e8dc3b9cd@kernel.org/
>
> This is incorrect use of the trait. The pointer is supposed to be
> opaque, and you can't dereference it. See my reply to that patch as
> well:
> https://lore.kernel.org/all/CAH5fLggDwPBzMO2Z48oMjDm4qgoNM0NQs_63TxmVEGy+gtMpOA@mail.gmail.com/


For reference, the outcome of the discussion yesterday:

 - The use of `ForeignOwnable` in the configfs series is not correct. The pointer
   must be opaque. I will drop the use of `ForeignOwnable` and adapt
   `Arc` methods `into_raw`/`from_raw` instead. I had a plan to make the
   code generic over the pointer type with a bound on `ForeignOwnable`.
   A new trait is required for that now.

 - There may be a use case for a trait that allows passing ownership of
   an object to C, similar to `ForeignOwnable` but with a non-opaque
   pointer. Trait methods would be `into_raw`, `from_raw`, `borrow`.

 - The solution for alignment adopted in this (xarray) series is not
   ideal. However, given the timeline we will proceed merging the series
   as is, and then change the solution to the one outlined by Gary in
   the next cycle.

@Gary you mentioned an implementation of the solution you outlined is
already posted to the list. I can't seem to find it, can you point to
it?

Best regards,
Andreas Hindborg