The DRIVER rule doesn't seem to work

The DRIVER rule doesn't seem to work

[Anthony Wright]

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.

I notice that this functionality is mirrored in udevinfo and wondered if 
the current DEVICE functionality is intentional. I can't see what use 
the current functionality is (and I can't find any documentation about 
it). If the current functionality is intentional, would it be possible 
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=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

Re: The DRIVER rule doesn't seem to work

[Kay Sievers]

On Sun, 2006-07-30 at 14:00 +0100, Anthony Wright wrote:
> 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,

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.

> (2) is ugly and (3) seems perfect but doesn't work.

Probably a timing problem, and it depends on the 'device' link, which
will go away along with the PHYSDEV* stuff.

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

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

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?

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

Re: The DRIVER rule doesn't seem to work

[Anthony Wright]

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

Re: The DRIVER rule doesn't seem to work

[Kay Sievers]

On Thu, 2006-08-03 at 09:40 +0100, Anthony Wright wrote:
> 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.

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.

> 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've added it a few days ago, but it will only be set if you ask for a
bus device.

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

Re: The DRIVER rule doesn't seem to work

[Anthony Wright]

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

Cheers,

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

Re: The DRIVER rule doesn't seem to work

[Kay Sievers]

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

Re: The DRIVER rule doesn't seem to work

[Anthony Wright]

Kay Sievers wrote:
> On Thu, 2006-08-03 at 10:45 +0100, Anthony Wright wrote:
>   
>> 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
>   
I get the same result from udevtest, so I tried a variation on the rule 
and changed it to the rule below.

  DRIVER="uhci_hcd", PROGRAM="/bin/sh -c '/bin/echo %p >>/tmp/udev.log'"

If I udevtest on /devices/pci0000:00/0000:00:1d.1, as expected I get an 
entry for it in the udev.log file. However if I remove udev.log, kill 
udevd, restart it and then udevtrigger, I get a udev.log that looks like:

/devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0
/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.2
/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.1
/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0
/devices/pci0000:00/0000:00:1d.3/usb5/5-0:1.0
/devices/pci0000:00/0000:00:1d.2/usb4/4-0:1.0
/devices/pci0000:00/0000:00:1d.1/usb3/3-0:1.0
/devices/pci0000:00/0000:00:1d.0/usb2/2-0:1.0
/devices/pci0000:00/0000:00:1d.2/usb4/4-1
/devices/pci0000:00/0000:00:1d.3/usb5
/devices/pci0000:00/0000:00:1d.1/usb3/3-1
/devices/pci0000:00/0000:00:1d.0/usb2
/devices/pci0000:00/0000:00:1d.2/usb4
/devices/pci0000:00/0000:00:1d.1/usb3
/class/usb_host/usb_host5
/class/usb_host/usb_host4
/class/usb_host/usb_host3
/class/usb_device/usbdev5.1
/class/usb_host/usb_host2
/class/usb_device/usbdev4.1
/class/usb_device/usbdev2.1
/class/input/input3/mouse2
/class/usb_device/usbdev4.2
/class/usb_device/usbdev3.1
/class/usb_device/usbdev3.2
/class/input/input3

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.

Tony.



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x120709&bid&3057&dat\x121642
_______________________________________________
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

Re: The DRIVER rule doesn't seem to work

[Kay Sievers]

On Fri, 2006-08-11 at 23:01 +0100, Anthony Wright wrote:
> Kay Sievers wrote:
> > On Thu, 2006-08-03 at 10:45 +0100, Anthony Wright wrote:

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

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

You are right, that doesn't work with the daemon, cause it avoids
looking at sysfs for the device we received the event for, if not really
needed.

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.

Thanks,
Kay


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x120709&bid&3057&dat\x121642
_______________________________________________
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

Re: The DRIVER rule doesn't seem to work

[Anthony Wright]

Kay Sievers wrote:
> 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.

Thanks,
Tony.



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x120709&bid&3057&dat\x121642
_______________________________________________
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

Re: The DRIVER rule doesn't seem to work

[Kay Sievers]

On Mon, 2006-08-14 at 08:29 +0100, Anthony Wright wrote:
> Kay Sievers wrote:
> > 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.

When it's added to the kernel, it will be in the event environment the
kernel sends out. The kernel event variables are not documented in udev.

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

Yes, the DRIVER key match will include the device, the event is received
for, but sure, only newer kernels will provide the needed variable.
ENV{DRIVER} will only match the event-device itself and not look at the
parent.

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

Yes, it is useful, cause you want to match a class device by the driver
of the bus device it comes from.

Kay


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x120709&bid&3057&dat\x121642
_______________________________________________
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

Re: The DRIVER rule doesn't seem to work

[Kay Sievers]

On Mon, 2006-08-14 at 08:29 +0100, Anthony Wright wrote:
> Kay Sievers wrote:
> > 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.

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.

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

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


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x120709&bid&3057&dat\x121642
_______________________________________________
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

Re: The DRIVER rule doesn't seem to work

[Kay Sievers]

On Thu, 2006-08-03 at 09:40 +0100, Anthony Wright wrote:
> 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.
> 
> >> 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.

Ok, it was on my TODO list for a very long time, but I never had a
convincing idea how to do this really. I talked to Marco over the
weekend and we have now the following more simpler and more consistent
scheme:

We have this now to match only the event device:
  KERNEL=
  SUBSYSTEM=
  ATTR=

And this, as just the plural form of the same key, to match all parents
along the device chain:
  KERNELS= (old ID)
  SUBSYSTEMS= (old BUS)
  ATTRS= (old SYSFS)
  DRIVERS= (old DRIVER)

The old keys BUS, ID, SYSFS will still work the same way as before, but
are not longer mentioned in the man page. DRIVER should be replaced by
DRIVERS. Some day we will change DRIVER to match only the event device.

Thanks,
Kay


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x120709&bid&3057&dat\x121642
_______________________________________________
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

Re: The DRIVER rule doesn't seem to work

[Anthony Wright]

Kay Sievers wrote:
>> 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.
>   
>> 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.
>>     
> >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
>   
This is super, many thanks.

Tony.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x120709&bid&3057&dat\x121642
_______________________________________________
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