Hello,
I'm trying to write a UDEV rule, which has to hand over the SCSI device
ID in the format $HOST:$CHANNEL:$ID:$LUN to a shellscript.
My first try was:
ATTR{vendor}=="XXXX", ATTR{model}=="XXXX", SUBSYSTEM=="scsi",
ACTION=="add", PROGRAM+="/usr/bin/test.sh %b %p"
This returns the SCSI device ID and the device path up to the SCSI
device to my test script.
As I would prefer to use the USB device information (idVendor,
idProduct) to detect the device, I also tried this one:
ATTRS{idVendor}=="0dda", ATTRS{idProduct}=="2005", SUBSYSTEM=="scsi",
ACTION=="add", PROGRAM+="/usr/bin/test.sh %b %p"
Now this version returns the USB device ID ($NUM-$NUM) to the test
script, but the device path (%p) is still OK and still goes down up to
the SCSI device ID.
Why does %b not return the SCSI device ID in the second rule?
Thanks in advance
Yours
Manuel
Manuel Reimer <[email protected]> writes:
> As I would prefer to use the USB device information (idVendor, idProduct)
> to detect the device, I also tried this one:
>
> ATTRS{idVendor}=="0dda", ATTRS{idProduct}=="2005", SUBSYSTEM=="scsi",
> ACTION=="add", PROGRAM+="/usr/bin/test.sh %b %p"
>
> Now this version returns the USB device ID ($NUM-$NUM) to the test script,
> but the device path (%p) is still OK and still goes down up to the SCSI
> device ID.
>
> Why does %b not return the SCSI device ID in the second rule?
Because ATTRS has matched the USB device, not the SCSI device.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Andreas Schwab wrote:
>> As I would prefer to use the USB device information (idVendor, idProduct)
>> to detect the device, I also tried this one:
>>
>> ATTRS{idVendor}=="0dda", ATTRS{idProduct}=="2005", SUBSYSTEM=="scsi",
>> ACTION=="add", PROGRAM+="/usr/bin/test.sh %b %p"
>>
>> Now this version returns the USB device ID ($NUM-$NUM) to the test script,
>> but the device path (%p) is still OK and still goes down up to the SCSI
>> device ID.
>>
>> Why does %b not return the SCSI device ID in the second rule?
>
> Because ATTRS has matched the USB device, not the SCSI device.
Yes, that's right, but "SUBSYSTEM" matched the SCSI device...
If I use udevinfo, then this tool tells me:
| A rule to match, can be composed by the attributes of the device
| and the attributes from one single parent device.
So I thought, that I've matched the SCSI device now. To prove this, I
just replaced "SUBSYSTEM=="scsi"" with "SUBSYSTEM=="usb"" and removed
the "S" in the "ATTRS" of the above rule, and now, I get the USB-device
in %b (as expected) and the path in %p only goes down up to the USB
device ID.
So, if all rules match for the same device, then %b and %p are both
pointing to this, right, device.
If I try to match, using one of the parent devices (using the "S"
"extension" to the property names) and the device, to match to, itself,
then the two are inconsistent. Then, %b holds the device name of the
parent and %p holds the patch of the device, I want to match.
For me, this looks like a bug, or am I wrong?
Yours
Manuel
Manuel Reimer <[email protected]> writes:
> For me, this looks like a bug, or am I wrong?
It's a feature. It's documented.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Andreas Schwab wrote:
> Manuel Reimer <[email protected]> writes:
>
>> For me, this looks like a bug, or am I wrong?
>
> It's a feature. It's documented.
man udev says:
| The name of the device matched while searching the devpath upwards
| for SUBSYSTEMS, KERNELS, DRIVERS and ATTRS.
What exactly does this mean?
Why should anyone need the name of a device, he didn't search for?
Could someone give me an example, where someone may be interested in an
device name of an device, he just used, to narrow his rule to the one
device, he is looking for.
Yours
Manuel
On 9/6/07, Manuel Reimer <[email protected]> wrote:
> Andreas Schwab wrote:
> >> As I would prefer to use the USB device information (idVendor, idProduct)
> >> to detect the device, I also tried this one:
> >>
> >> ATTRS{idVendor}=="0dda", ATTRS{idProduct}=="2005", SUBSYSTEM=="scsi",
> >> ACTION=="add", PROGRAM+="/usr/bin/test.sh %b %p"
> >>
> >> Now this version returns the USB device ID ($NUM-$NUM) to the test script,
> >> but the device path (%p) is still OK and still goes down up to the SCSI
> >> device ID.
> >>
> >> Why does %b not return the SCSI device ID in the second rule?
> >
> > Because ATTRS has matched the USB device, not the SCSI device.
>
> Yes, that's right, but "SUBSYSTEM" matched the SCSI device...
>
> If I use udevinfo, then this tool tells me:
>
> | A rule to match, can be composed by the attributes of the device
> | and the attributes from one single parent device.
>
> So I thought, that I've matched the SCSI device now. To prove this, I
> just replaced "SUBSYSTEM=="scsi"" with "SUBSYSTEM=="usb"" and removed
> the "S" in the "ATTRS" of the above rule, and now, I get the USB-device
> in %b (as expected) and the path in %p only goes down up to the USB
> device ID.
>
> So, if all rules match for the same device, then %b and %p are both
> pointing to this, right, device.
>
> If I try to match, using one of the parent devices (using the "S"
> "extension" to the property names) and the device, to match to, itself,
> then the two are inconsistent. Then, %b holds the device name of the
> parent and %p holds the patch of the device, I want to match.
>
> For me, this looks like a bug, or am I wrong?
It's fine. $id, like some other values too, is a value of the device
where all keys successful matched while walking up the chain of
devices.
Seems you are looking for the name of the device you received the
event for, so just use $kernel instead.
Kay
Kay Sievers wrote:
>>>> ATTRS{idVendor}=="0dda", ATTRS{idProduct}=="2005", SUBSYSTEM=="scsi",
>>>> ACTION=="add", PROGRAM+="/usr/bin/test.sh %b %p"
> It's fine. $id, like some other values too, is a value of the device
> where all keys successful matched while walking up the chain of
> devices.
But the "SUBSYSTEM" didn't match for the USB-device.
I still don't know, what %b contains and in which situation the value in
%b may help anyone.
> Seems you are looking for the name of the device you received the
> event for, so just use $kernel instead.
Yes, this did the job. Thanks for the hint.
CU
Manuel