Re: The DRIVER rule doesn't seem to work

[Kay Sievers <kay.sievers@vrfy.org>]

On Thu, 2006-08-03 at 10:45 +0100, Anthony Wright wrote:
> Kay Sievers wrote:
> >>>> 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.
> >>     
> > If you ask for a class device, it will never be set, cause class devices
> > don't have a driver, only parent devices which are created by a bus
> I don't think they are class devices, but I can't be 100% sure as I'm 
> still learning how all the device handling works.
> 
> The path to the devices and their driver symbolic links are:
> 
>       Path                                                   Driver Symlink
> a)    /sys/devices/pci0000:00/0000:00:1d.1                   uhci_hcd
> b)    /sys/devices/pci0000:00/0000:00:1d.1/usb2              usb
> c)    /sys/devices/pci0000:00/0000:00:1d.1/usb2/2-0:1.0      hub
> d)    /sys/devices/pci0000:00/0000:00:1d.1/usb2/2-1          usb
> e)    /sys/devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.0  NONE
> f)    /sys/devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.1  NONE
> g)    /sys/devices/pci0000:00/0000:00:1d.1/usb2/2-1/2-1:1.2  NONE
> 
> and there are a lot of references to the bus sub-directories in the logs.
> 
> The rule DRIVER="?*" for each of these devices according to match_key 
> matches the following matching values:
> 
>       Matching value
> a)    MATCHING FAILS
> b)    uhci_hcd
> c)    usb
> d)    usb
> e)    usb
> f)    usb
> g)    usb
> 
> This is consistant with DRIVER matching against a device's parents only, 
> not the device itself. If DRIVER also matched against the device I 
> believe the matching values should be as follows.
> 
>       Matching value
> a)    uhci_hcd
> b)    usb
> c)    hub
> d)    usb
> e)    usb
> f)    usb
> g)    usb

Hmm, that seems to work for me, for the device we receive the event for:
  DRIVER="uhci_hcd", PROGRAM="/bin/true usb"
  
  $ ls -l /sys/devices/pci0000:00/0000:00:1d.1/driver
  /sys/devices/pci0000:00/0000:00:1d.1/driver -> ../../../bus/pci/drivers/uhci_hcd

  $ udevtest /devices/pci0000:00/0000:00:1d.1
  main: looking at device '/devices/pci0000:00/0000:00:1d.1' from subsystem 'pci'
  run_program: '/bin/true usb'
  ...

Kay


-------------------------------------------------------------------------
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