The DRIVER rule doesn't seem to work

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.

Quoted 13 lines

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"

Quoted 9 lines

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.

Quoted 5 lines

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

Quoted 4 lines

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.

Quoted 3 lines

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?

Quoted 32 lines · Kay Sievers

Quoted 13 lines

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"

Quoted 9 lines

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.

Quoted 5 lines

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

Quoted 8 lines

Quoted 4 lines

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.

Quoted 7 lines

Quoted 7 lines

Quoted 4 lines

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.

Quoted 11 lines

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

Quoted 18 lines · Kay Sievers

Quoted 7 lines

Quoted 7 lines

Quoted 4 lines

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.

Quoted 11 lines

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.

Quoted 2 lines

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

Quoted 32 lines · Anthony Wright

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.

Quoted 9 lines

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

Quoted 22 lines · Kay Sievers

Quoted 4 lines · Anthony Wright

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.

Quoted 9 lines

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

Quoted 3 lines

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

I actually have 4 usb hubs which use the uhci_hcd driver (0000:00:1d.[0-3]). Unlike under udevtest, with udevd none of these match the rule, though all of their children do.

As all the PHYSDEV* variables should go away some day, cause they are just misleading, describe nothing necessarily 'physical', and 'class' devices should not have such values at all, we should add a DRIVER= key to all 'bus' devices as a replacement for the PHYSDEVDRIVER key now. Then we can could just check with ENV{DRIVER}. I will do this now.

Quoted 6 lines · Kay Sievers

As all the PHYSDEV* variables should go away some day, cause they are just misleading, describe nothing necessarily 'physical', and 'class' devices should not have such values at all, we should add a DRIVER= key to all 'bus' devices as a replacement for the PHYSDEVDRIVER key now. Then we can could just check with ENV{DRIVER}. I will do this now.

Would it be possible to provide a short explanation of the new ENV(DRIVER) variable? I had a look at the documentation in 097 and couldn't find anything.

Also, it would be really helpful to understand the DRIVER keyword as well. Does it now include the device as well as it's parents or still just the parents?

Also, while I'm sure there's a very good reason for
it, I'm still unclear why it's useful for the DRIVER keyword to examine the device's parents.

Quoted 5 lines · Kay Sievers

As all the PHYSDEV* variables should go away some day, cause they are just misleading, describe nothing necessarily 'physical', and 'class' devices should not have such values at all, we should add a DRIVER= key to all 'bus' devices as a replacement for the PHYSDEVDRIVER key now. Then we can could just check with ENV{DRIVER}. I will do this now.

Would it be possible to provide a short explanation of the new ENV(DRIVER) variable? I had a look at the documentation in 097 and couldn't find anything.

Also, it would be really helpful to understand the DRIVER keyword as well. Does it now include the device as well as it's parents or still just the parents? Also, while I'm sure there's a very good reason for it, I'm still unclear why it's useful for the DRIVER keyword to examine the device's parents.

Kay Sievers wrote:

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.

Quoted 27 lines

Quoted 3 lines

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=

Quoted 4 lines

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.

Quoted 4 lines

Would it be possible to provide a short explanation of the new ENV(DRIVER) variable? I had a look at the documentation in 097 and couldn't find anything.

Ok, we hopefully fixed that in 098. Newer kernels will add DRIVER to the event environment and udev 098 will just fake the same key for older kernels. ENV{DRIVER}= should work now for you, to determine at coldplug time, if a device is already bound to a driver.

Quoted 6 lines

Also, it would be really helpful to understand the DRIVER keyword as well. Does it now include the device as well as it's parents or still just the parents? Also, while I'm sure there's a very good reason for it, I'm still unclear why it's useful for the DRIVER keyword to examine the device's parents.

Quoted 1 line

From udev 098 on, we will have DRIVERS= (plural) to match all the

parents, and after a while we will switch DRIVER= to match only the event device (like ENV{DRIVER}) to be consistent.

Hope that all works now without using the deprecated PHYSDEV* stuff, Kay