KOBJ_BIND uevent

KOBJ_BIND uevent

[Jonas Bonn]

Hi,

I have a question about the ordering of uevents, specifically concerning 
complex USB devices that present multiple interfaces/functions.

Before KOBJ_BIND, a USB device would typically present itself as:

add usb_device
add usb_interface-1
add subsystem-device-1.0
add subsystem-device-1.1
add usb_interface-2
add subsystem-device-2.0

I have noted that the recently added "bind" actions, however, present in 
the reverse order.

bind subsystem-device-1.0
bind subsystem-device-1.1
bind usb-interface-1
bind subsystem-device-2.0
bind usb_interface-2
bind usb_device

This secondary ordering could be useful in the sense that the final 
"bind" action on the usb_device is an indication that the kernel has 
finished enumeration of all endpoints and has bound all drivers that it 
could to the available interfaces... i.e. no further events for this 
device are expected.

The question, then, is:  is the above ordering of "bind" events stable, 
or is it just a consequence of the current implementation and may change 
in the future?

/Jonas

Re: KOBJ_BIND uevent

[Greg KH]

On Mon, Nov 05, 2018 at 11:35:57AM +0100, Jonas Bonn wrote:
> Hi,
> 
> I have a question about the ordering of uevents, specifically concerning
> complex USB devices that present multiple interfaces/functions.
> 
> Before KOBJ_BIND, a USB device would typically present itself as:
> 
> add usb_device
> add usb_interface-1
> add subsystem-device-1.0
> add subsystem-device-1.1
> add usb_interface-2
> add subsystem-device-2.0
> 
> I have noted that the recently added "bind" actions, however, present in the
> reverse order.
> 
> bind subsystem-device-1.0
> bind subsystem-device-1.1
> bind usb-interface-1
> bind subsystem-device-2.0
> bind usb_interface-2
> bind usb_device
> 
> This secondary ordering could be useful in the sense that the final "bind"
> action on the usb_device is an indication that the kernel has finished
> enumeration of all endpoints and has bound all drivers that it could to the
> available interfaces... i.e. no further events for this device are expected.

Maybe.  Maybe not, as userspace might still be in the process of loading
new kernel drivers based on the add uevents that got sent out.  Then
binding would happen later after the usb_device was "bound".

> The question, then, is:  is the above ordering of "bind" events stable, or
> is it just a consequence of the current implementation and may change in the
> future?

Not stable at all, sorry, you can not depend on it.

Nor should you even try to, what problem are you wanting to solve here?

thanks,

greg k-h

Re: KOBJ_BIND uevent

[Jonas Bonn]

Hi,

On 05/11/2018 14:21, Greg KH wrote:
> On Mon, Nov 05, 2018 at 11:35:57AM +0100, Jonas Bonn wrote:
>> Hi,
>>
>> I have a question about the ordering of uevents, specifically concerning
>> complex USB devices that present multiple interfaces/functions.
>>
>> Before KOBJ_BIND, a USB device would typically present itself as:
>>
>> add usb_device
>> add usb_interface-1
>> add subsystem-device-1.0
>> add subsystem-device-1.1
>> add usb_interface-2
>> add subsystem-device-2.0
>>
>> I have noted that the recently added "bind" actions, however, present in the
>> reverse order.
>>
>> bind subsystem-device-1.0
>> bind subsystem-device-1.1
>> bind usb-interface-1
>> bind subsystem-device-2.0
>> bind usb_interface-2
>> bind usb_device
>>
>> This secondary ordering could be useful in the sense that the final "bind"
>> action on the usb_device is an indication that the kernel has finished
>> enumeration of all endpoints and has bound all drivers that it could to the
>> available interfaces... i.e. no further events for this device are expected.
> 
> Maybe.  Maybe not, as userspace might still be in the process of loading
> new kernel drivers based on the add uevents that got sent out.  Then
> binding would happen later after the usb_device was "bound".
> 
>> The question, then, is:  is the above ordering of "bind" events stable, or
>> is it just a consequence of the current implementation and may change in the
>> future?
> 
> Not stable at all, sorry, you can not depend on it.
> 
> Nor should you even try to, what problem are you wanting to solve here?

Specifically, I'm dealing with USB modems that fall into two categories:

i)  present a bunch of USB interfaces with one ACM (or similar) class 
device on each interface (one TTY for data, control, GPS, etc.)

ii)  present one interface with multiple endpoints that end up as 
multiple Linux devices (typically usbmisc device + network interface)

In both cases, the modem really isn't useful until all the 
interfaces/endpoints are ready.  It would be nice to be able to have one 
uevent that indicates that the kernel has done all it can with the 
device so we can evaluate whether we have everything we need.

Currently, we set a 1 second delay from the "add usb_device" before 
proceeding to evaluate the available modem interfaces; this delay is 
normally sufficient for everything to be enumerated and drivers bound, 
but it's still just an arbitrary delay.

Thanks,
Jonas

> 
> thanks,
> 
> greg k-h
> 

Re: KOBJ_BIND uevent

[Greg KH]

On Mon, Nov 05, 2018 at 02:44:21PM +0100, Jonas Bonn wrote:
> Hi,
> 
> On 05/11/2018 14:21, Greg KH wrote:
> > On Mon, Nov 05, 2018 at 11:35:57AM +0100, Jonas Bonn wrote:
> > > Hi,
> > > 
> > > I have a question about the ordering of uevents, specifically concerning
> > > complex USB devices that present multiple interfaces/functions.
> > > 
> > > Before KOBJ_BIND, a USB device would typically present itself as:
> > > 
> > > add usb_device
> > > add usb_interface-1
> > > add subsystem-device-1.0
> > > add subsystem-device-1.1
> > > add usb_interface-2
> > > add subsystem-device-2.0
> > > 
> > > I have noted that the recently added "bind" actions, however, present in the
> > > reverse order.
> > > 
> > > bind subsystem-device-1.0
> > > bind subsystem-device-1.1
> > > bind usb-interface-1
> > > bind subsystem-device-2.0
> > > bind usb_interface-2
> > > bind usb_device
> > > 
> > > This secondary ordering could be useful in the sense that the final "bind"
> > > action on the usb_device is an indication that the kernel has finished
> > > enumeration of all endpoints and has bound all drivers that it could to the
> > > available interfaces... i.e. no further events for this device are expected.
> > 
> > Maybe.  Maybe not, as userspace might still be in the process of loading
> > new kernel drivers based on the add uevents that got sent out.  Then
> > binding would happen later after the usb_device was "bound".
> > 
> > > The question, then, is:  is the above ordering of "bind" events stable, or
> > > is it just a consequence of the current implementation and may change in the
> > > future?
> > 
> > Not stable at all, sorry, you can not depend on it.
> > 
> > Nor should you even try to, what problem are you wanting to solve here?
> 
> Specifically, I'm dealing with USB modems that fall into two categories:
> 
> i)  present a bunch of USB interfaces with one ACM (or similar) class device
> on each interface (one TTY for data, control, GPS, etc.)
> 
> ii)  present one interface with multiple endpoints that end up as multiple
> Linux devices (typically usbmisc device + network interface)
> 
> In both cases, the modem really isn't useful until all the
> interfaces/endpoints are ready.  It would be nice to be able to have one
> uevent that indicates that the kernel has done all it can with the device so
> we can evaluate whether we have everything we need.

Yes, many many many people have wanted that pony for a few decades now,
there is no way for the kernel to provide you this "flag", sorry.

> Currently, we set a 1 second delay from the "add usb_device" before
> proceeding to evaluate the available modem interfaces; this delay is
> normally sufficient for everything to be enumerated and drivers bound, but
> it's still just an arbitrary delay.

If all of the kernel drivers are in the kernel at the moment, that
should be fine.  But yes, it is arbitrary, which is what happens with
dynamic devices, sorry.

good luck!

greg k-h