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@redhat.com> --- 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 :|