5:10 p.m.
udevGetUintProperty was called with base set to 0 for busnum and devnum.
With base 0 strtoul parses the number as octal if it start with a 0. But
busnum and devnum are decimal and udev returns them padded with leading
zeros. So strtoul parses them as octal. This works for certain decimal
values like 001-007, but fails for values like 008.
Change udevProcessUSBDevice to use base 10 for busnum and devnum.
---
src/node_device/node_device_udev.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c
index 734f3f7..0c0f29a 100644
--- a/src/node_device/node_device_udev.c
+++ b/src/node_device/node_device_udev.c
@@ -500,14 +500,14 @@ static int udevProcessUSBDevice(struct udev_device *device,
if (udevGetUintProperty(device,
"BUSNUM",
&data->usb_dev.bus,
- 0) == PROPERTY_ERROR) {
+ 10) == PROPERTY_ERROR) {
goto out;
}
if (udevGetUintProperty(device,
"DEVNUM",
&data->usb_dev.device,
- 0) == PROPERTY_ERROR) {
+ 10) == PROPERTY_ERROR) {
goto out;
}
--
1.6.3.3
7:36 p.m.
On 02/01/2010 06:10 PM, Matthias Bolte wrote:
udevGetUintProperty was called with base set to 0 for busnum and
devnum.
With base 0 strtoul parses the number as octal if it start with a 0. But
busnum and devnum are decimal and udev returns them padded with leading
zeros. So strtoul parses them as octal. This works for certain decimal
values like 001-007, but fails for values like 008.
This is a good change, but I thought it was already fixed a couple of
weeks ago. You're sure they're returned decimal and not hex? ACK
assuming that's the case.
Change udevProcessUSBDevice to use base 10 for busnum and devnum.
---
src/node_device/node_device_udev.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c
index 734f3f7..0c0f29a 100644
--- a/src/node_device/node_device_udev.c
+++ b/src/node_device/node_device_udev.c
@@ -500,14 +500,14 @@ static int udevProcessUSBDevice(struct udev_device *device,
if (udevGetUintProperty(device,
"BUSNUM",
&data->usb_dev.bus,
- 0) == PROPERTY_ERROR) {
+ 10) == PROPERTY_ERROR) {
goto out;
}
if (udevGetUintProperty(device,
"DEVNUM",
&data->usb_dev.device,
- 0) == PROPERTY_ERROR) {
+ 10) == PROPERTY_ERROR) {
goto out;
}
2:52 a.m.
2010/2/2 Dave Allan <dallan(a)redhat.com>:
On 02/01/2010 06:10 PM, Matthias Bolte wrote:
>
> udevGetUintProperty was called with base set to 0 for busnum and devnum.
> With base 0 strtoul parses the number as octal if it start with a 0. But
> busnum and devnum are decimal and udev returns them padded with leading
> zeros. So strtoul parses them as octal. This works for certain decimal
> values like 001-007, but fails for values like 008.
This is a good change, but I thought it was already fixed a couple of weeks
ago. You're sure they're returned decimal and not hex? ACK assuming that's
the case.
vendor, device and ID_MODEL_ID where changed to be parsed as hex some weeks ago.
I based my assumption that busnum and devnum are decimal on the lsusb
manpage, because the udev driver output matches the lsusb output. The
manpage says busnum and devnum are decimal and it also says that
vendor is hex.
I just found a libvirt bugreport [1] that confirms my assumption. Also
googling for 'lsusb "bus X"' with X as decimal and hex numbers gives
no result with hex numbers like 00A, but gives results for decimal
numbers like 010, 011, etc. So I'm pretty sure that busnum and devnum
are decimal :)
Okay, I pushed this one.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=508645
Matthias
8:35 a.m.
On 02/02/2010 03:52 AM, Matthias Bolte wrote:
2010/2/2 Dave Allan<dallan(a)redhat.com>:
> On 02/01/2010 06:10 PM, Matthias Bolte wrote:
>>
>> udevGetUintProperty was called with base set to 0 for busnum and devnum.
>> With base 0 strtoul parses the number as octal if it start with a 0. But
>> busnum and devnum are decimal and udev returns them padded with leading
>> zeros. So strtoul parses them as octal. This works for certain decimal
>> values like 001-007, but fails for values like 008.
>
> This is a good change, but I thought it was already fixed a couple of weeks
> ago. You're sure they're returned decimal and not hex? ACK assuming
that's
> the case.
>
vendor, device and ID_MODEL_ID where changed to be parsed as hex some weeks ago.
I based my assumption that busnum and devnum are decimal on the lsusb
manpage, because the udev driver output matches the lsusb output. The
manpage says busnum and devnum are decimal and it also says that
vendor is hex.
I just found a libvirt bugreport [1] that confirms my assumption. Also
googling for 'lsusb "bus X"' with X as decimal and hex numbers gives
no result with hex numbers like 00A, but gives results for decimal
numbers like 010, 011, etc. So I'm pretty sure that busnum and devnum
are decimal :)
Excellent--many thanks!
Dave
Okay, I pushed this one.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=508645
Matthias
5409
days inactive
5410
days old
3 comments
2 participants
participants (2)
-
Dave Allan -
Matthias Bolte