On 12/16/2010 09:50 AM, Daniel P. Berrange wrote:
The qemu_conf.c code is doing three jobs, driver config file loading, QEMU capabilities management and QEMU command line management. Move the capabilities code into its own file
* src/qemu/qemu_capabilities.c, src/qemu/qemu_capabilities.h: New capabilities management code * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Delete capabilities code * src/qemu/qemu_conf.h: Adapt for API renames * src/Makefile.am: add src/qemu/qemu_capabilities.c --- src/Makefile.am | 1 + src/qemu/qemu_capabilities.c | 1253 ++++++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_capabilities.h | 113 ++++ src/qemu/qemu_conf.c | 1191 +--------------------------------------- src/qemu/qemu_conf.h | 81 --- src/qemu/qemu_driver.c | 55 +- 6 files changed, 1398 insertions(+), 1296 deletions(-) create mode 100644 src/qemu/qemu_capabilities.c create mode 100644 src/qemu/qemu_capabilities.h
+ +static void +uname_normalize (struct utsname *ut) +{ + uname(ut); + + /* Map i386, i486, i586 to i686. */ + if (ut->machine[0] == 'i' && + ut->machine[1] != '\0' && + ut->machine[2] == '8' && + ut->machine[3] == '6' && + ut->machine[4] == '\0') + ut->machine[1] = '6'; +}
This one helper function wasn't removed from qemu_conf.c; since both files want to use it, shouldn't it be exposed in a common header and shared, rather than duplicating it? Other than that nit, ACK - this appeared to be straight code motion plus fallout from renaming to a consistent API (thanks for not trying to squash any cleanups into the code motion, although I certainly spotted some followup cleanups that would be nice such as converting virExec to virCommand). -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org