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@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