[libvirt] [PATCH] udev: Parse PCI devices even if libpciaccess fails
We only use libpciaccess for resolving device product/vendor. If initializing the library fails (say if using qemu:///session), don't warn so loudly, and carry on as usual. Signed-off-by: Cole Robinson <crobinso@redhat.com> --- src/node_device/node_device_udev.c | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 73217c5..f872483 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -363,12 +363,15 @@ static int udevTranslatePCIIds(unsigned int vendor, char **vendor_string, char **product_string) { - int ret = -1; + int ret = -1, pciret; struct pci_id_match m; const char *vendor_name = NULL, *device_name = NULL; - if (pci_system_init() != 0) { - VIR_ERROR0(_("Failed to initialize libpciaccess")); + if ((pciret = pci_system_init()) != 0) { + char ebuf[1024]; + VIR_INFO("Failed to initialize libpciaccess: %s", + virStrerror(pciret, ebuf, sizeof ebuf)); + ret = 0; goto out; } -- 1.6.6.1
On Wed, Jun 30, 2010 at 04:38:37PM -0400, Cole Robinson wrote:
We only use libpciaccess for resolving device product/vendor. If initializing the library fails (say if using qemu:///session), don't warn so loudly, and carry on as usual.
Signed-off-by: Cole Robinson <crobinso@redhat.com> --- src/node_device/node_device_udev.c | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 73217c5..f872483 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -363,12 +363,15 @@ static int udevTranslatePCIIds(unsigned int vendor, char **vendor_string, char **product_string) { - int ret = -1; + int ret = -1, pciret; struct pci_id_match m; const char *vendor_name = NULL, *device_name = NULL;
- if (pci_system_init() != 0) { - VIR_ERROR0(_("Failed to initialize libpciaccess")); + if ((pciret = pci_system_init()) != 0) { + char ebuf[1024]; + VIR_INFO("Failed to initialize libpciaccess: %s", + virStrerror(pciret, ebuf, sizeof ebuf)); + ret = 0; goto out; }
-- 1.6.6.1
1024 seems like a big buffer to allocate on the stack, and I'd be surprised if an error message was more than 256 bytes. Does it really need to be that large? ACK, other than that. Dave
On 06/30/2010 05:02 PM, Dave Allan wrote:
On Wed, Jun 30, 2010 at 04:38:37PM -0400, Cole Robinson wrote:
We only use libpciaccess for resolving device product/vendor. If initializing the library fails (say if using qemu:///session), don't warn so loudly, and carry on as usual.
Signed-off-by: Cole Robinson <crobinso@redhat.com> --- src/node_device/node_device_udev.c | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 73217c5..f872483 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -363,12 +363,15 @@ static int udevTranslatePCIIds(unsigned int vendor, char **vendor_string, char **product_string) { - int ret = -1; + int ret = -1, pciret; struct pci_id_match m; const char *vendor_name = NULL, *device_name = NULL;
- if (pci_system_init() != 0) { - VIR_ERROR0(_("Failed to initialize libpciaccess")); + if ((pciret = pci_system_init()) != 0) { + char ebuf[1024]; + VIR_INFO("Failed to initialize libpciaccess: %s", + virStrerror(pciret, ebuf, sizeof ebuf)); + ret = 0; goto out; }
-- 1.6.6.1
1024 seems like a big buffer to allocate on the stack, and I'd be surprised if an error message was more than 256 bytes. Does it really need to be that large?
Not sure if it's strictly required, I just followed one of the examples in qemu_driver.c. I'll change it to 256 when I commit
ACK, other than that.
Dave
On 06/30/2010 05:02 PM, Dave Allan wrote:
On Wed, Jun 30, 2010 at 04:38:37PM -0400, Cole Robinson wrote:
We only use libpciaccess for resolving device product/vendor. If initializing the library fails (say if using qemu:///session), don't warn so loudly, and carry on as usual.
Signed-off-by: Cole Robinson <crobinso@redhat.com> --- src/node_device/node_device_udev.c | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 73217c5..f872483 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -363,12 +363,15 @@ static int udevTranslatePCIIds(unsigned int vendor, char **vendor_string, char **product_string) { - int ret = -1; + int ret = -1, pciret; struct pci_id_match m; const char *vendor_name = NULL, *device_name = NULL;
- if (pci_system_init() != 0) { - VIR_ERROR0(_("Failed to initialize libpciaccess")); + if ((pciret = pci_system_init()) != 0) { + char ebuf[1024]; + VIR_INFO("Failed to initialize libpciaccess: %s", + virStrerror(pciret, ebuf, sizeof ebuf)); + ret = 0; goto out; }
-- 1.6.6.1
1024 seems like a big buffer to allocate on the stack, and I'd be surprised if an error message was more than 256 bytes. Does it really need to be that large?
ACK, other than that.
Dropped it to 256 and pushed Thanks, Cole
participants (2)
-
Cole Robinson -
Dave Allan