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