Re: [libvirt] anyone implementing host device enumeration?
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 :|