On Fri, Oct 03, 2008 at 02:35:06PM -0400, David Lively wrote: > I definitely wasn't planning on covering all of HAL :-) > > I assume you weren't planning on exposing these capability-specific > representations in the public API. Right? (If not, ignore the rest of > this ...) Not at this time. For the forseeable future I expect the XML format to be the only publically exposed representation of configuration. A long time down the road when we're confident the representation is long term sustainable & correct, we might consider exposing the structs, but that is a long way off. > So I guess I don't see the value of having these cap-specific internal > representations. I keep a string array of the cap names for > ListDevicesByCap, but other than that, the capability data is used only > by virNodeDeviceGetXMLDesc(). So it seems natural to represent it in a > form that can easily be converted to XML, and that can represent all the > XML we'll need to output (like xmlNode). Otherwise, we are forced to > write more capability-specific code, with no particular advantage (no > stronger typing guarantees if we don't expose specific cap types). The idea is that by having formal internal representations it makes it easier for internal driver code to work with it in a gaurenteed consistent fashion. While the structs may only be used by your specific driver for the intiial commit, experiance has shown our needs evolve over time and we'll probably end up with other internal code wanting it. We previously had each hypervisor driver using an adhoc representation internally for domain configs, and it just wasn't sustainable our internal usage evolved. > P.S. I do think it would be useful to have access to capability details > other than GetXMLDesc. Perhaps: > const char *virNodeDeviceCapabilityProperty(virNodeDevicePtr dev, > const char *cap, > const char *prop) > but note this exposes them only in a general (property / value) way, and > is quite easily implemented with a xmlNode representation. I'm wary of exposing sub-sets of the XML docs in simple key/value pairs because our XML formats have tended to expand over time, so things that started off key/value pairs gained extra attributes/child elements, all of which are desired. It is simple enough for applications to wrap in a property 'getter' using XPath on the XML doc if desired - virt-manager does this internally for many things. 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