On Monday, November 09, 2015 01:32:04 PM Thierry Reding wrote: > 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.
Well, the problem is that device_release_driver() cannot fail, so it pretty much has to unbind everything that is not going to work after the driver is unbound from the device. > 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 can be done for bus types having device_offline/online() support, but the number of these is quite limited at this point. The "offline" operation, as opposed to device_release_driver(), can return an error code to indicate that the device cannot be taken offline at this time. So, if offlining a supplier would require offlining all consumers of it, that may be made fail in certain situation. However, that would require quite a bit of additional structure (and complexity) in pretty much all bus types, so I wouldn't start with it at least. > 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. I actually think that those things are at least partly orthogonal. Thanks, Rafael
signature.asc
Description: This is a digitally signed message part.
