Hello, On 08/19/2010 02:24 PM, Kay Sievers wrote: > The compiled-in drivers have matched and bound and blocked-out any > other driver of the device long before udev is even started load the > other drivers. The matching compiled-in drivers will always win over > the modules, regardless of their priority. > > Is that what you mean? :) It's still a bit fuzzy to me. So, the exact scenario I'm thinking about is something like the following. 1. System discovers an unsupported IDE class controller. 2. udev kicks in and loads pata_acpi for it which can serve as a fallback driver for all IDE class controllers. 3. System discovers a controller which is supported by ata_piix. ata_piix is the correct driver for it w/ higher priority than pata_acpi. I'm curious about the followings, a. udev invokes modprobe on device added events, no? Does it matter whether there's a matching driver in the kernel (built-in or an already loaded module) to udev behavior? You seem to be implying that if there's a matching driver, udev wouldn't invoke modprobe at all. b. modprobe, when invoked, will load all the matching drivers in link order. If udev invokes modprobe regardless of existing drivers, is there a mechanism to hold off device - driver matching before modprobe is finished? Probably not, right? The whole priority thing seems kind of broken. It's good enough for simple cases but just breaks down as soon as things get closer to corner cases. Maybe it's best to leave it alone as mostly working workaround for simple problems. :-( Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
