Re: [libvirt] [PATCH 01/10] s/qemud/qemu/ in QEMU driver sources

> Change some legacy function names to use 'qemu' as their > prefix instead of 'qemud' which was a hang over from when > the QEMU driver ran inside a separate daemon > > Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com&gt; > --- > src/qemu/qemu_conf.c | 4 +- > src/qemu/qemu_conf.h | 4 +- > src/qemu/qemu_driver.c | 541 > ++++++++++++++++++++++--------------------- > src/qemu/qemu_monitor_text.c | 6 +- > src/qemu/qemu_process.c | 2 +- > 5 files changed, 280 insertions(+), 277 deletions(-) Fairly mechanical. I'll see if I can spot why there are more lines added than deleted... > > -static void qemudNotifyLoadDomain(virDomainObjPtr vm, int newVM, > void *opaque) > +static void qemuNotifyLoadDomain(virDomainObjPtr vm, int newVM, void > *opaque) [Yuck - I'll be glad to get off of this brain-dead web interface, as it sure mangles patch reviews] Is it worth a followup patch for lines like this to use our more common convention of: static void qemuNotifyLoadDomain(...) But that doesn't impact this patch.

> @@ -1130,7 +1130,7 @@ static virDrvOpenStatus qemudOpen(virConnectPtr > conn, > return VIR_DRV_OPEN_SUCCESS; > } > > -static int qemudClose(virConnectPtr conn) { > +static int qemuClose(virConnectPtr conn) { > struct qemud_driver *driver = conn->privateData; As long as we are refactoring code... Another one bugging me is that we use 'struct qemud_driver *' everywhere instead of a nicer typedef'd 'qemuDriverPtr'; but that would also be best done as a separate patch.

ACK. This will cause conflicts to any outstanding patches or to backports of patches made after this point, but I think we can live with that; besides, we seem to be past the worst of the backport churn (observent list readers can probably pinpoint cycles of major backport efforts vs. major feature development).