[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH5fLgge1pp10a8w4xp1eDobMJUHpnM1Ezh+JHmVmfF=6_vpTQ@mail.gmail.com>
Date: Wed, 15 Jan 2025 09:27:39 +0100
From: Alice Ryhl <aliceryhl@...gle.com>
To: Boqun Feng <boqun.feng@...il.com>
Cc: Daniel Almeida <daniel.almeida@...labora.com>, Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...nel.org>,
Trevor Gross <tmgross@...ch.edu>, linux-kernel@...r.kernel.org,
rust-for-linux@...r.kernel.org
Subject: Re: [PATCH] rust: irq: add support for request_irq()
On Wed, Jan 15, 2025 at 1:47 AM Boqun Feng <boqun.feng@...il.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.
Alice
Powered by blists - more mailing lists