Re: [PATCH v4 5/5] rust: devres: implement register_release()

["Benno Lossin" <lossin@kernel.org>]

On Sat Jun 28, 2025 at 8:38 AM CEST, Boqun Feng wrote:
> On Sat, Jun 28, 2025 at 08:06:52AM +0200, Benno Lossin wrote:
>> On Sat Jun 28, 2025 at 12:06 AM CEST, Boqun Feng wrote:
>> > On Fri, Jun 27, 2025 at 01:19:53AM +0200, Benno Lossin wrote:
>> >> On Thu Jun 26, 2025 at 10:48 PM CEST, Danilo Krummrich wrote:
>> >> > On Thu, Jun 26, 2025 at 01:37:22PM -0700, Boqun Feng wrote:
>> >> >> On Thu, Jun 26, 2025 at 10:00:43PM +0200, Danilo Krummrich wrote:
>> >> >> > +/// [`Devres`]-releaseable resource.
>> >> >> > +///
>> >> >> > +/// Register an object implementing this trait with [`register_release`]. Its `release`
>> >> >> > +/// function will be called once the device is being unbound.
>> >> >> > +pub trait Release {
>> >> >> > +    /// The [`ForeignOwnable`] pointer type consumed by [`register_release`].
>> >> >> > +    type Ptr: ForeignOwnable;
>> >> >> > +
>> >> >> > +    /// Called once the [`Device`] given to [`register_release`] is unbound.
>> >> >> > +    fn release(this: Self::Ptr);
>> >> >> > +}
>> >> >> > +
>> >> >> 
>> >> >> I would like to point out the limitation of this design, say you have a
>> >> >> `Foo` that can ipml `Release`, with this, I think you could only support
>> >> >> either `Arc<Foo>` or `KBox<Foo>`. You cannot support both as the input
>> >> >> for `register_release()`. Maybe we want:
>> >> >> 
>> >> >>     pub trait Release<Ptr: ForeignOwnable> {
>> >> >>         fn release(this: Ptr);
>> >> >>     }
>> >> >
>> >> > Good catch! I think this wasn't possible without ForeignOwnable::Target.
>> >> 
>> >> Hmm do we really need that? Normally you either store a type in a shared
>> >
>> > I think it might be quite common, for example, `Foo` may be a general
>> > watchdog for a subsystem, for one driver, there might be multiple
>> > devices that could feed the dog, for another driver, there might be only
>> > one. For the first case we need Arc<Watchdog> or the second we can do
>> > Box<Watchdog>.
>> 
>> I guess then the original `&self` design is better? Not sure...
>> 
>
> This is what you said in v3:
>
> """
> 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.
> Or if they store the value in an `Arc<T>`, they have the option to clone
> it and give it to somewhere else.
> """
>
> I think that's the reason why we think the current version (the
> associate type design) is better than `&self`?

Yeah and I'd still say that that statement is true.

> The generic type design (i.e. Release<P: ForeignOwnable>) just further
> allows this "different behaviors between Box and Arc" for the same type
> T. I think it's a natural extension of the current design and provides
> some better flexibility.

I think that extension is going to end up being too verbose.

>> > What's the downside?
>> 
>> You'll need to implement `Release` twice:
>> 
>
> Only if you need to support both for `Foo`, right? You can impl only one
> if you only need one.
>
> Also you can do:
>
>     impl<P: ForeignOwnable<Target=Foo> + Deref<Target=Foo>> Release<P> for Foo {
>         fn release(this: P) {
> 	    this.deref().do_sth();
> 	}
>     }

Please no. If this is a regular pattern, then let's go back to `&self`.
You lose all benefits of the generic design if you do it like this,
because you don't know the concrete type of the foreign ownable.

> if you want Box and Arc case share the similar behavior, right?
>
>>     impl Release<Box<Self>> for Foo {
>>         fn release(this: Box<Self>) {
>>             /* ... */
>>         }
>>     }
>> 
>>     impl Release<Arc<Self>> for Foo {
>>         fn release(this: Arc<Self>) {
>>             /* ... */
>>         }
>>     }
>> 
>> This also means that you can have different behavior for `Box` and
>> `Arc`...
>
> That's the point, as one of the benefits you mentioned above for the
> associate type design, just extending it to the same type.

I'd say that's too verbose for something that's rather supposed to be
simple.

Hmm @Danilo, do you have any use-cases in mind or already done?

---
Cheers,
Benno