[libvirt] Re: [PATCH 0/6] host ("node") device enumeration, take two

[Daniel P. Berrange]

On Tue, Oct 21, 2008 at 01:45:47PM -0400, David Lively wrote:
> Ok, here's my substantially-reworked node device enumeration patch, this
> time done with a proper understanding of the public-obj/Obj/Def
> model :-) as last discussed here:
> https://www.redhat.com/archives/libvir-list/2008-September/msg00398.html
> 
> I've broken it into the following pieces:
>   1-public-api			additions to the public API
>   2-internal-api		additions to the internal API
>   3-local-node-drivers		the HAL & DeviceKit implementations
>   4-remote-node-driver		the remote driver
>   5-virsh-support		virsh support
>   6-python-bindings		python bindings
> 
> Big differences from the last submission:
>   * public-obj/Obj/Def object model finally understood :-)
>   * capabilities structure now struct-ified, handled like
>     other Def bits

I like the way this bit turned out - makes it very clear what properties
we are exporting in the XML as part of our API/ABI gaurentee.

>   * using newfangled array-based lists for NodeDeviceObj's

The individual capabilities within a device are still using a linked list,
though that's not a critical problem from the thread safety point of view.

>   * added flags args to various public APIs (as suggested by Dan V)
>   * "bus" folded into capabilities (as discussed w/Dan B)

Yes, this looks much nicer too.

>   * device "key" no longer exists - name is unique on node
> 
> Some pieces are still incomplete, but I thought it would be better to
> post what I have since it's useful "as is".  Here's what I know of
> that's left to do:
>   * finish Python bindings (will get to Real Soon Now)
>   * submit Java bindings (I have them, and have been using them)
>   * implement virNodeDeviceCreate/Destroy (I have no plans for these)

No need to worry about this - I'd like to use them to implement the
creation/deletion of NPIV virtual HBAs eventually.

>   * subscribe to HAL events & update dev state from them (next for me?)
>   * implement pci_bus/usb_bus capabilities (for PCI/USB controllers)

While on the subject of USB, I've just noticed that HAL seems to
expose 2 devices for every USB device - 'usb' and 'usb_device',
which we're mapping into just a 'usb' capability. Unless there's
compelling reason to have both we might consider just filtering
out one of the two.

>   * DeviceKit implementation is barely a proof of concept

Noticed one problem - on my build it refuses to enumerate devices
if you pass in a NULL for subsystem name list. I made a really
quick & dirty hack to just try it out

@@ -300,13 +301,18 @@ static int devkitNodeDriverStartup(void)
     }
 
     /* Populate with known devices */
-    devs = devkit_client_enumerate_by_subsystem(devkit_client, NULL, &err);
-    if (err) {
-        DEBUG0("devkit_client_enumerate_by_subsystem failed");
-        devs = NULL;
-        goto failure;
+    for (i = 0 ; i < ARRAY_CARDINALITY(caps_tbl) ; i++) {
+        const char *caps[] = { caps_tbl[i].cap_name, NULL };
+        devs = devkit_client_enumerate_by_subsystem(devkit_client,
+                                                    caps,
+                                                    &err);
+        if (err) {
+            DEBUG0("devkit_client_enumerate_by_subsystem failed");
+            devs = NULL;
+            goto failure;
+        }
+        g_list_foreach(devs, dev_create, devkit_client);
     }
-    g_list_foreach(devs, dev_create, devkit_client);
 
     driverState->privateData = devkit_client;
 


>     * need to resolve naming & other issues (see
> https://www.redhat.com/archives/libvir-list/2008-September/msg00430.html
>     * ... and then fill in impl (no hurry; devkit immature now)

I'm still wondering if it is worth us santizing the device names ourselves
somehow, though it might end up being rather a large job.  Will have to
think some more about it.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|