[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20499935-B328-4DE3-AFBF-B692FA3434E5@collabora.com>
Date: Tue, 14 Jan 2025 15:57:57 -0300
From: Daniel Almeida <daniel.almeida@...labora.com>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>,
Boqun Feng <boqun.feng@...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()
>
> 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?
— Daniel
Powered by blists - more mailing lists