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
