On Thu, Aug 19, 2010 at 14:33, Tejun Heo <tj@xxxxxxxxxx> wrote:
> I'm curious about the followings,
>
> a. udev invokes modprobe on device added events, no?
Yeah, in this case it from off of the pci devices. Most of the events
for pci devices run in parallel.
> Does it matter
> whether there's a matching driver in the kernel (built-in or an
> already loaded module) to udev behavior?
If the device we are currently handling has already a driver bound,
udev will not call modprobe.
It's:
DRIVER!="?*", ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe -bv $env{MODALIAS}"
which means:
!DRIVER && MODALIAS -> modprobe
> You seem to be implying
> that if there's a matching driver, udev wouldn't invoke modprobe at
> all.
It doesn't call modprobe for this device in that case, yes. But some
other similar device may still cause the driver to be loaded and every
driver load will scan all devices and try to bind them.
> b. modprobe, when invoked, will load all the matching drivers in link
> order. If udev invokes modprobe regardless of existing drivers,
Yeah, udev only cares about the device state, and if the device has a
driver bound, not if there are other drivers (bound or unbound to
devices) in the kernel already.
> is
> there a mechanism to hold off device - driver matching before
> modprobe is finished? Probably not, right?
What does 'modprobe finished' mean? The modprobe called for this
specific device? The first driver loaded and initialized will win. If
multiple drivers are loaded with the same modprobe call, the later
ones will never see the device.
Kay
--
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
