Re: Order in which kernel decides binding device driver

Please use Reply-To-All so that your responses show up on the mailing 
list.

On Sun, May 16, 2021 at 10:38:14AM +0530, Hritik Vijay wrote:

On Sat, May 15, 2021 at 09:01:54PM -0400, Alan Stern wrote:

quoted

I believe this happens in the order that the drivers are registered.  
For drivers in modules, this will be the order in which the modules are 
loaded.

Can you please reference the code snippet with this ? If it happens in

There is no such snippet.  This is an emergent effect; it happens 
because __device_attach in drivers/base/dd.c calls bus_for_each_drv to 
try to match drivers with a new device, bus_for_each_drv in bus.c uses 
next_driver to iterate through the list of drivers on a bus, next_driver 
uses klist_next to follow the klist of driver knodes, and bus_add_driver 
calls klist_add_tail to add a new driver knode to the end of the klist 
of drivers for a bus.

the order in which the modules are loaded then I suppose its the
responsibility of the hot-plugging daemon (udev here) to take care of
the load order.

No; load order is nobody's responsibility.  Making sure the system works 
correctly is the responsibility of the programmers who wrote the device 
drivers (is that you in this case?).  Drivers are supposed to work as 
desired no matter what order they get probed in.

quoted

driver will be able to manage a particular device.  For cases where 
there are two drivers capable of handling the same device, people 
usually have some sort of priority scheme to decide.  For example, many 
USB mass-storage devices can be handled by either the usb-storage or the 
uas driver, but uas has higher priority.

Alan Stern

I'm curious about the case where no particular priority is defined.

In that case there is no definite requirement.  Either driver may be 
probed first and consequently may end up binding to the device; the 
result is more or less random.  It may even differ from one boot to the 
next.

Hrtk

Alan Stern

On Sun, May 16, 2021 at 10:41:18AM -0400, Alan Stern wrote:

Please use Reply-To-All so that your responses show up on the mailing 
list.

On Sun, May 16, 2021 at 10:38:14AM +0530, Hritik Vijay wrote:

quoted

On Sat, May 15, 2021 at 09:01:54PM -0400, Alan Stern wrote:

quoted

I believe this happens in the order that the drivers are registered.  
For drivers in modules, this will be the order in which the modules are 
loaded.

Can you please reference the code snippet with this ? If it happens in

There is no such snippet.  This is an emergent effect; it happens 
because __device_attach in drivers/base/dd.c calls bus_for_each_drv to 
try to match drivers with a new device, bus_for_each_drv in bus.c uses 
next_driver to iterate through the list of drivers on a bus, next_driver 
uses klist_next to follow the klist of driver knodes, and bus_add_driver 
calls klist_add_tail to add a new driver knode to the end of the klist 
of drivers for a bus.

quoted

the order in which the modules are loaded then I suppose its the
responsibility of the hot-plugging daemon (udev here) to take care of
the load order.

No; load order is nobody's responsibility.  Making sure the system works 
correctly is the responsibility of the programmers who wrote the device 
drivers (is that you in this case?).  Drivers are supposed to work as 
desired no matter what order they get probed in.

quoted

quoted

driver will be able to manage a particular device.  For cases where 
there are two drivers capable of handling the same device, people 
usually have some sort of priority scheme to decide.  For example, many 
USB mass-storage devices can be handled by either the usb-storage or the 
uas driver, but uas has higher priority.

Alan Stern

I'm curious about the case where no particular priority is defined.

In that case there is no definite requirement.  Either driver may be 
probed first and consequently may end up binding to the device; the 
result is more or less random.  It may even differ from one boot to the 
next.

quoted

Hrtk

Alan Stern

Thank you so much for the detailed reply. Having looked at dd.c and
bus.c, it now makes much more sense to me.

Hrtk