From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Wright Date: Thu, 03 Aug 2006 08:40:12 +0000 Subject: Re: The DRIVER rule doesn't seem to work Message-Id: <44D1B66C.9010401@communitymesh.com> List-Id: References: <44CCAD5F.9010407@communitymesh.com> In-Reply-To: <44CCAD5F.9010407@communitymesh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org Kay Sievers wrote: >> 1) >> ENV{PHYSDEVDRIVER}=3D"?*", GOTO=3D"driver_already_loaded" >> ACTION=3D"add", ENV{MODALIAS}=3D"?*", RUN+=3D"/sbin/modprobe $env{MODALI= AS}" >> # >> 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{MODALI= AS}" >> # >> LABEL=3D"driver_already_loaded" >> >> 3) >> DRIVER=3D"?*", GOTO=3D"driver_already_loaded" >> ACTION=3D"add", ENV{MODALIAS}=3D"?*", RUN+=3D"/sbin/modprobe $env{MODALI= AS}" >> # >> LABEL=3D"driver_already_loaded" >> >> Of these (1) I understand uses an obsolete variable that will be removed= =20 >> in kernel 2.6.18, >> =20 > > PHYSDEV* will not go away with the next kernel. It will be scheduled for > removal when we converted all users of sysfs to /sys/devices, which will > take a while. > =20 >> (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=20 >> 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=20 >> ancestor's drivers (parent, grandparent etc, but not the device itself),= =20 >> and returning their driver if they have one. >> =20 > > Sure, it looks a the device itself, but also walks up the parents and > finds a DRIVER value there. > =20 I had a good look at this, and from what I can tell it only looks at the=20 device's parents, not the device itself. I compiled and ran udev with=20 debug to see what was going on (and have lots of logs if you're=20 interested), but the short version is that while udev makes a DRIVER=20 test for the device, it looks like the driver field hasn't been loaded=20 for the device, only for the device's parents. From my logs, it seems=20 that to load values for the device the function=20 sysfs_device_set_values() is called in isolation, while for the parents=20 sysfs_device_get() is called which calls sysfs_device_set_values(), but=20 also sets the driver field. While I felt this was rather strange, i also noticed that udevinfo -a -p=20 only displays a driver for the parents, not for the driver=20 itself. Since both pieces of code are consistant, I wondered if this was=20 intentional behaviour, even though I couldn't work out why you would=20 want it that way, and it's the opposite of what I need. >> I believe DRIVER should return only the driver of the device, and not=20 >> its ancestors. >> =20 > It's like all not event-specific rule keys work, they look up the chain > of parents. Only ACTION, KERNEL, SUBSYSTEM, DEVPATH are matched against > the event device only. DRIVER, BUS, ID, SYSFS walks up the chain. > > Usually you just select the device you want to match the DRIVER value > with BUS=3D (which is the subsystem value of the parent). The difference > between BUS and SUBSYSTEM is only, that BUS matches also against the > parents. Same logic for KERNEL and ID. That all has historical reasons > only, cause it took us quite a while to find out what we really need for > the rules. > > In your case DRIVER can't work, that's right. In a lot of other cases it > is useful that it looks at the parent. > > So, ideally we would just have: > KERNEL=3D > SUBSYSTEM=3D > DRIVER=3D > SYSFS{}=3D > > deprecate the use of: > BUS=3D > ID=3D > > and use some syntax switch at KERNEL, SUBSYSTEM, DRIVER, SYSFS to > signify if we want to look at the parents or not. That may be more > consistent, than the current key names? > =20 Something like this would be exactly what I'm looking for. Thanks, Tony. ------------------------------------------------------------------------- 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