The DRIVER rule doesn't seem to work

[Anthony Wright <anthony@communitymesh.com>]

I have a monolithic 2.6.16 linux kernel with udev-096 - mainly LFS 
6.1.1, with the udev rules take from LFS-6.2-pre2 (LFS = 
www.linuxfromscratch.org). The current udev rules with LFS 6.2-pre2 are 
designed for use with a modular kernel, and get confused when presented 
with a monolithic kernel, creating excessive entries in the 
/dev/.udev/failed directory.

The problem arises from the use of modprobe to determine whether a 
device has a driver. The rules assume that if modprobe fails, the device 
doesn't have a driver and therefore there is an error. However on a 
monolithic if the driver is compiled into the kernel, even if the device 
has a driver, the modprobe will fail and an entry ends up in 
/dev/.udev/failed.

Current rule.....

ACTION="add", ENV{MODALIAS}="?*", RUN+="/sbin/modprobe $env{MODALIAS}"
# <other modprobe rules>

The way to fix would seem to be to explicitly check whether the device 
has a driver and only do the modprobe if it doesn't already have a 
driver. There would seem to be three ways to do this:

1)
ENV{PHYSDEVDRIVER}="?*", GOTO="driver_already_loaded"
ACTION="add", ENV{MODALIAS}="?*", RUN+="/sbin/modprobe $env{MODALIAS}"
# <other modprobe rules>
LABEL="driver_already_loaded"

2)
PROGRAM="/bin/sh -c '[ -e /sys$$DEVPATH/driver -o -e 
/sys$$DEVPATH/device/driver ]'", GOTO="driver_already_loaded"
ACTION="add", ENV{MODALIAS}="?*", RUN+="/sbin/modprobe $env{MODALIAS}"
# <other modprobe rules>
LABEL="driver_already_loaded"

3)
DRIVER="?*", GOTO="driver_already_loaded"
ACTION="add", ENV{MODALIAS}="?*", RUN+="/sbin/modprobe $env{MODALIAS}"
# <other modprobe rules>
LABEL="driver_already_loaded"

Of these (1) I understand uses an obsolete variable that will be removed 
in kernel 2.6.18, (2) is ugly and (3) seems perfect but doesn't work.

(1) and (2) give identical results on my machine, and are the results I 
expect (some of my devices don't have drivers). (3) gives different 
results, returning no driver for devices which I know have drivers, and 
drivers for devices which I know do not have drivers.

What I believe is happening is that DRIVER is looking at the device's 
ancestor's drivers (parent, grandparent etc, but not the device itself), 
and returning their driver if they have one.

For example I have an internal bluetooth card connected to an internal 
usb hub. The usb hub has a driver, the bluetooth card does not. For the 
bluetooth card, DRIVER returns the driver of the usb hub (the hub is the 
bluetooth card's parent). For the usb hub, DRIVER returns nothing 
because the usb hub does not have a parent.

I believe DRIVER should return only the driver of the device, and not 
its ancestors.

I notice that this functionality is mirrored in udevinfo and wondered if 
the current DEVICE functionality is intentional. I can't see what use 
the current functionality is (and I can't find any documentation about 
it). If the current functionality is intentional, would it be possible 
to implement a new rule that implements the functionality I describe?

Thanks,

Tony Wright.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel