[libvirt] [PATCH] lib: implement new API to retrieve the list of CPU models

Daniel P. Berrange berrange at redhat.com
Thu Aug 22 09:36:55 UTC 2013

On Wed, Aug 21, 2013 at 10:46:36PM +0200, Giuseppe Scrivano wrote:
> Eric Blake <eblake at redhat.com> writes:
> > I'm not sure whether returning XML or a straight-up list makes more
> > sense.  If you used char ***models, then the user would get an array of
> > directly-usable strings, "486", "pentium", ..., instead of a document
> > that has to be parsed.  On the other hand, your idea of returning XML
> > lets us return information for multiple arches simultaneously. But do we
> > need that flexibility, since arch is also an input parameter?  Is the
> > idea that you pass arch=NULL to get the full list, or arch="x86" to get
> > the x86 subset of the xml?  Why not just make arch mandatory and return
> > char ***; but then you have the question of which arches are supported.
> I've thought a bit about XML vs Array and whether specifying the arch in
> the returned XML snippet or not, and these are the reasons behind my
> choice:
> the same way as it is done by virConnectBaselineCPU.  It might turn
> useful in future to get all the data in one shot, without requiring
> additional round-trips for each model trough virConnectBaselineCPU.

I don't think returning a list of all cpus with all features is
an operation that will be common, or performance critical.
So do not want to see us replicating virConnectBaselineCPU
functionality here.

> 2) as you said, support arch=NULL to get the full list (and now that
> I've thought more about it, I should change the error to
> VIR_ERR_NO_SUPPORT when arch==NULL instead of raising an internal
> error).

I'd strictly forbid arch=NULL in the API and wire protocol
(ie use remote_nonnull_string arch).

|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

More information about the libvir-list mailing list