Re: [PATCH] rust: irq: add support for request_irq()

[Daniel Almeida <daniel.almeida@collabora.com>]

> On 15 Jan 2025, at 11:39, Boqun Feng <boqun.feng@gmail.com> wrote:
> 
> On Wed, Jan 15, 2025 at 09:27:39AM +0100, Alice Ryhl wrote:
>> On Wed, Jan 15, 2025 at 1:47 AM Boqun Feng <boqun.feng@gmail.com> wrote:
>>> 
>>> On Tue, Jan 14, 2025 at 03:57:57PM -0300, Daniel Almeida wrote:
>>>> 
>>>>> 
>>>>> It's not the pin_init! stuff, but the Opaque stuff. If it fails, then
>>>>> it runs the destructor of Opaque<T>, which does *not* run the
>>>>> destructor of T.
>>>>> 
>>>>> Alice
>>>> 
>>>> This is pretty unintuitive if you take into account trivial examples like
>>>> 
>>>> ```
>>>> struct Foo(T)
>>>> ```
>>>> 
>>>> Where dropping Foo drops T.
>>>> 
>>>> Is there any reason why dropping Opaque<T> doesn’t behave similarly?
>>>> 
>>> 
>>> Because `Opaque` implies the value may not be initialized, it's similar
>>> to `MaybeUninit`.
>>> 
>>> Do you really need the `Opaque` here? C code won't touch `handler` if
>>> I'm not missing anything.
>> 
>> The irq callback is given access to handler, so it could touch it at any time.
>> 
> 
> You're right it could, but would it? C code doesn't know the concrete
> type of the handler, so what it usually does is just passing the
> pointers to the Rust code (again).
> 
> A similar case the `func` field in `ClosureWork`: it doesn't need to be
> `Opaque`, although workqueue callback may access it.
> 
> Am I missing something here? Daniel, why this has to be `Opaque`? Could
> you explain?
> 
> Regards,
> Boqun
> 
>> Alice

As Alice said, !Unpin is the main requirement. Although it’s not clear whether this can’t be
achieved through a PhantomPinned<T> instead.

Again, Opaque<T> needs to have its docs updated to more thoroughly explain when it should
be used. My understanding relies on what is written, i.e.: a transparent wrapper providing
!Unpin, UnsafeCell and a *mut T API for an owned T.

One could very well think this is the default thing to reach for to build anything wrapping a bindgen type.

Note that “blob of bytes that shouldn’t be touched” is not explicitly written down in the docs. What is in the docs
is a vague  “objects that are never interpreted by the Rust side”.


— Daniel