Messages in this thread | | | Date | Mon, 9 Nov 2015 13:32:04 +0100 | From | Thierry Reding <> | Subject | Re: [RFD] Functional dependencies between devices |
| |
On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote: [...] > There's a question about what if the supplier device is being unbound before > the consumer one (for example, as a result of a hotplug event). My current > view on that is that the consumer needs to be force-unbound in that case too, > but I guess I may be persuaded otherwise given sufficiently convincing > arguments.
I think this would be a huge step towards making the kernel more robust with little driver or subsystem code having to be duplicated. Currently most provider/consumer subsystems are fragile in that there isn't proper reference counting. Many subsystems will happily allow you to remove any of the provider, regardless of whether or not it has consumers. Most of the subsystems will make sure that modules can't be unloaded, but beyond that won't be able to prevent drivers from being unbound (either when a device is unplugged or unbound via sysfs). Even with proper reference counting there is no easy way to deal with devices going away (you'd need some sort of revoke semantics implemented for all providers, and consumers must be able to handle that situation gracefully).
Implementing a force-unbind policy would make this a whole lot easier. Dangling resources will automatically become a thing of the past. The downside of course is that force-unbinding consumers may not always be the most user-friendly course of action. Consider an SD/MMC slot that uses a GPIO as card-detect pin. Unbinding the provider of the GPIO would cause the SD/ MMC controller to be unbound, hence unmounting the filesystem that it provided. That filesystem might have been the root filesystem.
We discussed similar use-cases a while back and you proposed making the force-unbind policy be two-staged: reject unbind (-EBUSY) if there are any consumers, and force-unbind consumers if the provider was forcibly unbound (or caused by hot-unplug of the backing device). That sounds like a good compromise to me.
That said I can also imagine subsystems where a reliable mechanism is in place to properly hotplug and -unplug providers. The good thing about the functional dependencies mechanism you propose here is that it's an optional mechanism that drivers use from ->probe(). Subsystems where a better mechanism exists can simply choose to do without functional dependencies.
Thierry [unhandled content-type:application/pgp-signature] | |