Order in which kernel decides binding device driver

Order in which kernel decides binding device driver

[Hritik Vijay]

Hello

I've experimented with two device drivers targeting a single device,
both hot-pluggable. When the device plugs in, both the modules are loaded.
This is expected behavior of udev. After being loaded, only one of the
drivers offered by them is chosen to be bound to the device
i.e. only one module gets to execute their `probe` function.

I tried looking through the source to find out which module would get
the preference but I would really like some clarification on the
topic. 
In what order will the kernel decide to give opportunities to device 
drivers to bind to a device ?

Hrtk

Re: Order in which kernel decides binding device driver

[Alan Stern]

On Sun, May 16, 2021 at 02:22:22AM +0530, Hritik Vijay wrote:
> Hello
> 
> I've experimented with two device drivers targeting a single device,
> both hot-pluggable. When the device plugs in, both the modules are loaded.
> This is expected behavior of udev. After being loaded, only one of the
> drivers offered by them is chosen to be bound to the device
> i.e. only one module gets to execute their `probe` function.
> 
> I tried looking through the source to find out which module would get
> the preference but I would really like some clarification on the
> topic. 
> In what order will the kernel decide to give opportunities to device 
> drivers to bind to a device ?

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.

In practice the loading order usually doesn't matter, because only one 
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

Re: Order in which kernel decides binding device driver

[Alan Stern]

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

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

Re: Order in which kernel decides binding device driver

[Hritik Vijay]

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:
> > On Sat, May 15, 2021 at 09:01:54PM -0400, Alan Stern wrote:
> > > 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.
> 
> > > 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

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