[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aF1TEuotIIwcKODM@cassiopeiae>
Date: Thu, 26 Jun 2025 16:02:58 +0200
From: Danilo Krummrich <dakr@...nel.org>
To: Benno Lossin <lossin@...nel.org>
Cc: gregkh@...uxfoundation.org, rafael@...nel.org, ojeda@...nel.org,
alex.gaynor@...il.com, boqun.feng@...il.com, gary@...yguo.net,
bjorn3_gh@...tonmail.com, a.hindborg@...nel.org,
aliceryhl@...gle.com, tmgross@...ch.edu, david.m.ertman@...el.com,
ira.weiny@...el.com, leon@...nel.org, kwilczynski@...nel.org,
bhelgaas@...gle.com, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: [PATCH v3 4/4] rust: devres: implement register_release()
On Thu, Jun 26, 2025 at 01:15:34PM +0200, Danilo Krummrich wrote:
> On Thu, Jun 26, 2025 at 12:36:23PM +0200, Benno Lossin wrote:
> > Or, we could change `Release` to be:
> >
> > pub trait Release {
> > type Ptr: ForeignOwnable;
> >
> > fn release(this: Self::Ptr);
> > }
> >
> > and then `register_release` is:
> >
> > pub fn register_release<T: Release>(dev: &Device<Bound>, data: T::Ptr) -> Result
> >
> > This way, one can store a `Box<T>` and get access to the `T` at the end.
>
> I think this was also the case before? Well, it was P::Borrowed instead.
>
> > Or if they store the value in an `Arc<T>`, they have the option to clone
> > it and give it to somewhere else.
>
> Anyways, I really like this proposal of implementing the Release trait.
One downside seems to be that the compiler cannot infer T anymore with this
function signature.
Powered by blists - more mailing lists