Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1265620 > unrolled thread

Re: [RFD] Functional dependencies between devices

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFD] Functional dependencies between devices Thierry Reding <treding@nvidia.com> - 2015-11-09 13:40 +0100
    Re: [RFD] Functional dependencies between devices "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-11-09 22:20 +0100

#1265620 — Re: [RFD] Functional dependencies between devices

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

#1266025

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web