Re: [libvirt] anyone implementing host device enumeration?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]