Re: [PATCH RFC] ata: Intel IDE-R support

[Tejun Heo <tj@kernel.org>]

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