On Mon Sep 22, 2025 at 5:10 PM CEST, Jason Gunthorpe wrote:
As was said later in this thread, it would be a real shame to see people implement revocable in drivers instead of rely on subsystems to have sane unregistration semantics where the subsystem guarentees that no driver callbacks are running after unregister. You never need driver revocable in a world like that.
I fully agree with that, in C there is indeed no value of a revocable type when subsystems can guarantee "sane unregistration semantics".
I say "in C" because in C there is no way to get a proof by the compiler that we're in a scope (e.g. through the subsystem guarentee) where the device is guaranteed to be bound (which we can in Rust).
So, effectively, we're not getting any value out of the revocable in C in such a case: In the best case, we're just bypassing the revocable by accessing the pointer unchecked (regardless whether that's valid or not); in the worst case we're introducing a useless SRCU read side critical section.
(In Rust the compiler will stop us from accessing the pointer unchecked if we're not in a scope where unchecked access is valid.)
So, I think in C revocable should be restricted to use-cases where scopes are unbound by design. DRM device callbacks are an example for that and it's the reason why things like drm_dev_{enter,exit}() and drm_dev_unplug() exist. In the end, those are exactly the same as revocable implemented in a slightly different way.
- Danilo