On 10/17/25 6:07 PM, Tzung-Bi Shih wrote:
Imagining:
- Driver X provides the res1.
- Driver Y provides the res2.
- Driver Z provides the chardev /dev/zzz. The file operations use res1 and res2.
- A userspace program opened /dev/zzz.
In the approach, what is .remove() of driver X supposed to do when driver X is unbinding (e.g. due to device unplug)?
There are use-cases for revocable, but this example is a bit too generic:
Drivers don't just share device resources with other random drivers, they usually have a defined relationship through a bus.
For instance, if you have a driver on the platform bus and another driver connected through the auxiliary bus, there is a defined lifetime: The auxiliary device has to be unbound before its parent device.
This means that as long as you are in a scope where your auxiliary device is bound, it is safe to use a device resource from that parent without further checks.
The goal should always be to proof to be in such a scope when accessing device resources (in Rust we can let the compiler ensure this at compile time :).
However, there are rare (yet valid) cases where such a scope can't be guaranteed. DRM has such cases, and, unfortunately, MISC device seems to be another one.
I know the reasons why DRM has to have this design, I'm not sure about MISC device though. Unless there's a good reason, I think MISC device should be "fenced" instead.