On Fri, Sep 12, 2025 at 06:22:48PM +0200, Danilo Krummrich wrote: > On 9/12/25 4:54 PM, Laurent Pinchart wrote: > > On Fri, Sep 12, 2025 at 04:44:56PM +0200, Bartosz Golaszewski wrote: > >> On Fri, Sep 12, 2025 at 4:40 PM Greg Kroah-Hartman wrote: > >>> Either way, I think this patch series stands on its own, it doesn't > >>> require cdev to implement it, drivers can use it to wrap a cdev if they > >>> want to. We have other structures that want to do this type of thing > >>> today as is proof with the rust implementation for the devm api. > >> > >> Yeah, I'm not against this going upstream. If more development is > >> needed for this to be usable in other parts of the kernel, that can be > >> done gradually. Literally no subsystem ever was perfect on day 1. > > > > To be clear, I'm not against the API being merged for the use cases that > > would benefit from it, but I don't want to see drivers using it to > > protect from the cdev/unregistration race. > > I mean, revocable is really a synchronization primitive in the end that > "revokes" access to some resource in a race free way. > > So, technically, it probably belongs into lib/. > > I think the reason it ended up in drivers/base/ is that one common use case is > to revoke a device resource from a driver when the device is unbound from this > driver; or in other words devres is an obvious user. > > So, I think that any other API (cdev, devres, etc.) should be built on top > of it.
No issue with that. I'm sure there are people who have better knowledge than me when it comes to implementing the low-level primitive in the most efficient way. What I have lots of experience with is the impact of API design on drivers, and the API misuse (including through cargo-cult programming) this can generate. Let's design the API towards drivers correctly. > This is also what we do in Rust, Revocable is just a common synchronization > primitive and the (only) user it has is currently Devres building on top of > it. -- Regards, Laurent Pinchart
