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@xxxxxxxxxx> >> --- >> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list