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

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

On Wed, Jan 15, 2025 at 03:42:44PM +0100, Alice Ryhl wrote:
> On Wed, Jan 15, 2025 at 3:39 PM 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?
> 
> It needs to be !Unpin, otherwise it's not safe for Rust to access the
> pointer. ClosureWork is not the same because there are no *other*

Could you elaborate it, maybe with an example? I asked because the data
wrapped by `handler` can only be exposed as an immutable reference to
safe Rust code, so how could Rust code access unsafely? The pointers are
always not noalias in Rust PoV. Thanks!

Regards,
Boqun

> references to it than the workqueue.
> 
> Alice