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.
