From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Wright Date: Sun, 30 Jul 2006 12:58:33 +0000 Subject: The DRIVER rule doesn't seem to work Message-Id: <44CCAD5F.9010407@communitymesh.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org I have a monolithic 2.6.16 linux kernel with udev-096 - mainly LFS=20 6.1.1, with the udev rules take from LFS-6.2-pre2 (LFS =3D=20 www.linuxfromscratch.org). The current udev rules with LFS 6.2-pre2 are=20 designed for use with a modular kernel, and get confused when presented=20 with a monolithic kernel, creating excessive entries in the=20 /dev/.udev/failed directory. The problem arises from the use of modprobe to determine whether a=20 device has a driver. The rules assume that if modprobe fails, the device=20 doesn't have a driver and therefore there is an error. However on a=20 monolithic if the driver is compiled into the kernel, even if the device=20 has a driver, the modprobe will fail and an entry ends up in=20 /dev/.udev/failed. Current rule..... ACTION=3D"add", ENV{MODALIAS}=3D"?*", RUN+=3D"/sbin/modprobe $env{MODALIAS}" # The way to fix would seem to be to explicitly check whether the device=20 has a driver and only do the modprobe if it doesn't already have a=20 driver. There would seem to be three ways to do this: 1) ENV{PHYSDEVDRIVER}=3D"?*", GOTO=3D"driver_already_loaded" ACTION=3D"add", ENV{MODALIAS}=3D"?*", RUN+=3D"/sbin/modprobe $env{MODALIAS}" # LABEL=3D"driver_already_loaded" 2) PROGRAM=3D"/bin/sh -c '[ -e /sys$$DEVPATH/driver -o -e=20 /sys$$DEVPATH/device/driver ]'", GOTO=3D"driver_already_loaded" ACTION=3D"add", ENV{MODALIAS}=3D"?*", RUN+=3D"/sbin/modprobe $env{MODALIAS}" # LABEL=3D"driver_already_loaded" 3) DRIVER=3D"?*", GOTO=3D"driver_already_loaded" ACTION=3D"add", ENV{MODALIAS}=3D"?*", RUN+=3D"/sbin/modprobe $env{MODALIAS}" # LABEL=3D"driver_already_loaded" Of these (1) I understand uses an obsolete variable that will be removed=20 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=20 expect (some of my devices don't have drivers). (3) gives different=20 results, returning no driver for devices which I know have drivers, and=20 drivers for devices which I know do not have drivers. What I believe is happening is that DRIVER is looking at the device's=20 ancestor's drivers (parent, grandparent etc, but not the device itself),=20 and returning their driver if they have one. For example I have an internal bluetooth card connected to an internal=20 usb hub. The usb hub has a driver, the bluetooth card does not. For the=20 bluetooth card, DRIVER returns the driver of the usb hub (the hub is the=20 bluetooth card's parent). For the usb hub, DRIVER returns nothing=20 because the usb hub does not have a parent. I believe DRIVER should return only the driver of the device, and not=20 its ancestors. I notice that this functionality is mirrored in udevinfo and wondered if=20 the current DEVICE functionality is intentional. I can't see what use=20 the current functionality is (and I can't find any documentation about=20 it). If the current functionality is intentional, would it be possible=20 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=3Djoin.php&p=3Dsourceforge&CID=DEVD= EV _______________________________________________ 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