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

[Boqun Feng <boqun.feng@gmail.com>]

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