Re: [PATCH] Allow userspace to request device probing even if defer_all_probes is true

[Matthew Garrett]

On Wed, Jan 4, 2017 at 2:03 PM, Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, Jan 04, 2017 at 01:53:45PM -0600, Matthew Garrett wrote:
>> 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.

It's not? The reason for implementing it this way is to avoid
duplicating functionality the kernel already has, especially when it's
impossible to precisely duplicate that behaviour in userspace.

>> 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.

That doesn't work - the USB authorisation code doesn't give you enough
information to make that decision before driver binding occurs.

> I'm getting the impression that somehow these two different patches are
> a series and related to each other which is even more confusing...

Yes, this is only relevant with the other patch.