On 09/10/2013 08:38 AM, Daniel P. Berrange wrote:
On Sat, Sep 07, 2013 at 01:11:22AM +0200, 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(a)redhat.com>
> ---
> include/libvirt/libvirt.h.in | 18 +++++++++++++
> python/generator.py | 1 +
> src/cpu/cpu.c | 64 ++++++++++++++++++++++++++++++++++++++++++++
> src/cpu/cpu.h | 3 +++
> src/driver.h | 7 +++++
> src/libvirt.c | 47 ++++++++++++++++++++++++++++++++
> src/libvirt_private.syms | 1 +
> src/libvirt_public.syms | 5 ++++
> tools/virsh-host.c | 48 +++++++++++++++++++++++++++++++++
> tools/virsh.pod | 5 ++++
It is preferrable to have virsh changes separate from the public API
addition. Likewise I'd suggest th src/cpu/ changes be a separate patch.
I can go either way regarding virsh + libvirt.c - virsh changes at the
same time as the public API prove that the public API is usable from a
coding perspective. Git history says we've done both approaches in the
past.
But I totally agree that libvirt.c + src/cpu should be separate;
committing the API first and then adding the implementation makes for a
nice division.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org