On Wed, Jan 04, 2017 at 01:53:45PM -0600, Matthew Garrett wrote: > On Wed, Jan 4, 2017 at 1:42 PM, Greg Kroah-Hartman > <[email protected]> wrote: > > On Wed, Jan 04, 2017 at 12:11:49PM -0600, Matthew Garrett wrote: > >> Userspace doesn't know the order that the kernel will use when > >> attempting to bind drivers, so punting binding out to userspace may > >> result in different behaviour. > > > > How can the order in which drivers are bound result in different > > behavior? > > If you have two loaded drivers that could bind to the device then the > order you attempt to bind them in will matter.
If you have that, you are screwed no matter what. The driver model never guarantees any order in which a driver and device is matched up, sorry, and if that's the goal of this patch somehow, then I'll strongly object to it. What in-kernel drivers do we have that bind to the same device? We shouldn't have that, because of this very issue. > >> The kernel already has the code to do this, so we should just reuse > >> it. > > > > That's fine, but I don't understand the problem you are trying to solve, > > please explain better. What am I missing here? > > If you plug in a device while defer_all_probes is true, it won't be > bound - that's the point. But if you have a USB keyboard and unplug it > and plug it, you'd then end up with no keyboard. So you want userspace > to be able to make an appropriate policy decision around which devices > should be bound, and you need a mechanism to allow userspace to > trigger that binding. Use the in-place mechanism for that, userspace gets notification that the device was plugged in, it can authorize it or not. That's what systems have been doing for a while now, and is what that api was created for. I'm getting the impression that somehow these two different patches are a series and related to each other which is even more confusing... thanks, greg k-h
