[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aF0rzzlKgwopOVHV@pollux>
Date: Thu, 26 Jun 2025 13:15:27 +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 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.
> Related questions:
>
> * should we implement `ForeignOwnable` for `&'static T`?
There's already a patch on the list doing this in the context of DebugFS [1].
[1] https://lore.kernel.org/lkml/20250624-debugfs-rust-v7-3-9c8835a7a20f@google.com/
> * should we require `'static` in `ForeignOwnable`? At the moment we only
> have those kinds supported and it only makes sense, a foreign owned
> object can be owned for any amount of time (so it must stay valid
> indefinitely).
Sounds reasonable to me.
Powered by blists - more mailing lists