Re: The DRIVER rule doesn't seem to work

[Anthony Wright <anthony@communitymesh.com>]

Kay Sievers wrote:
>> 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,
>>     
>
> 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.
>   
>> (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.
>>     
>
> Sure, it looks a the device itself, but also walks up the parents and
> finds a DRIVER value there.
>   
I had a good look at this, and from what I can tell it only looks at the 
device's parents, not the device itself. I compiled and ran udev with 
debug to see what was going on (and have lots of logs if you're 
interested), but the short version is that while udev makes a DRIVER 
test for the device, it looks like the driver field hasn't been loaded 
for the device, only for the device's parents. From my  logs, it seems 
that to load values for the device the function 
sysfs_device_set_values() is called in isolation, while for the parents 
sysfs_device_get() is called which calls sysfs_device_set_values(), but 
also sets the driver field.

While I felt this was rather strange, i also noticed that udevinfo -a -p 
<path> only displays a driver for the parents, not for the driver 
itself. Since both pieces of code are consistant, I wondered if this was 
intentional behaviour, even though I couldn't work out why you would 
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 
>> its ancestors.
>>     
> 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= (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=
>   SUBSYSTEM=
>   DRIVER=
>   SYSFS{}=
>
> deprecate the use of:
>   BUS=
>   ID=
>
> 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?
>   
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=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