[libvirt] Re: [PATCH 0/6] host ("node") device enumeration, take two
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 :|