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 ebl...@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
