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

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

 



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




[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]