On Wed, Aug 21, 2013 at 01:19:24PM -0600, Eric Blake wrote: > On 08/21/2013 01:02 PM, Giuseppe Scrivano wrote: > > The new function virConnectGetCPUModelNames allows to retrieve the list > > of CPU models known by the hypervisor for a specific architecture. > > > > Signed-off-by: Giuseppe Scrivano <gscrivan@xxxxxxxxxx> > > --- > > I have collected your comments on my RFC patch into this new version. I've > > replaced "virConnectGetCPUMapDesc" with "virConnectGetCPUModelNames". > > Good that the above paragraph is below the ---... > > > > > The new function signature is: > > > > int > > virConnectGetCPUModelNames(virConnectPtr conn, const char *arch, char **models, > > unsigned int flags); > > > > It returns (in MODELS) the list of CPU models formatted as an XML document, > > like: > > > > <models> > > <arch name='x86'> > > <model name='486'/> > > <model name='pentium'/> > > <model name='pentium2'/> > > <model name='pentium3'/> > > <model name='pentiumpro'/> > > <model name='coreduo'/> > > ... > > </arch> > > </models> > > ...but this is useful 6 months down the road, and should be in the > commit message proper, above the ---. > > 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. > > So, let's get agreement on the best design before worrying about > implementation (I'm still 50/50 on whether xml vs. char*** makes more > sense, without more discussion to sway me one way or the other). My intention was that we return a direct list of strings representing model names, *not* any XML. XML only comes into play when they they query the full CPU feature set from virConnectBaselineCPU. Daniel -- |: 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list