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(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org