Alexander E. Patrakov wrote:
Anthony Wright wrote:
ACTION=="add", ENV{MODALIAS}=="?*", RUN+="/bin/sh -c '/sbin/modprobe
$$MODALIAS ; [ -e /sys$$DEVPATH/driver -o -e
/sys$$DEVPATH/device/driver ] '"
This is indeed too long. Maybe (untested, relies on obsolete
PHYSDEVDRIVER variable, will certainly break with linux-2.6.18):
ENV{PHYSDEVDRIVER}=="?*", GOTO="driver_already_loaded"
ACTION=="add", ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe $env{MODALIAS}"
# <other modprobe rules>
LABEL="driver_already_loaded"
Hi Alex,
I tried this out, and it gives the same results as my modification which
I verified as the results I would expect. So from that perspective it
does the job and it's a simpler change, but if it's an obsolete
environmental variable that's going to dissappear in the near future it
seems a little pointless to start using it. Having said that, I did
notice that it's still used in the udev-096 (current version) examples.
I therefore had a wander through udev, and found a 'DRIVER' rules
keyword which looked hopeful, however when I tried to use it I got
different results from what I believe should be the 'correct' contents
of my /dev/.udev.failed/ directory. I wandered through the code of udev
and isolated this down to the way the DRIVER keyword seems to work
(couldn't find any documentation). The keywords seems to ignore the
driver of the device it's actually being applied to, and instead tries
to match against the device's parent devices' drivers (parent,
grandparent, great-grandparent etc).
For example I have an integrated usb hub to which an integrated usb
bluetooth card is attached. The usb hub uses the uhci_hcd driver while
the bluetooth card doesn't have a driver. However the DRIVER keyword
will match true for uhci_hcd on the bluetooth card, but won't match
anything on the usb hub, so that if I use a rule DRIVER=="?*" in place
of the PHYSDEVDRIVER the usb hub ends up in /dev/.udev/failed/ while the
bluetooth card doesn't.
I would have gone as far as to say this is a bug in udev, but udevinfo
seems to suggest this is desired functionality as it won't report a
driver for the device you request information on, but it will supply the
driver for it's parent devices. However, this now means I simply don't
understand what the purpose of the DRIVER keyword is, even though I see
a few people using it.
I'm not quite sure what the best way to progress from here is. Using my
original approach works, but it's ugly. You're approach is more elegant,
but it going to obselete very shortly. Using the DRIVER keyword instead
would be nicer, but it's either buggy and needs to be fixed or is
intended for another purpose. Maybe it's a request for a change in udev
to supply a new keyword. Finally we just forget about the whole thing
because it's not a big enough problem.
I'd appreciate your thoughts on this (and anybody else who feels like
chipping it :)
Sorry if I'm being stupid here, I'm trying to get to grips with linux's
device management system, and at the same time fix something in LFS
which is annoying me.
Cheers,
Tony.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
