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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list