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

[Daniel P. Berrange]

On Tue, Nov 27, 2012 at 01:38:44PM -0500, Eric Blake wrote:
> > 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 at redhat.com>
> > ---
> >  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.

I'll look at doing that & the other similar things you mention
in another patch, so that this remains just a rename rather
than re-style.

> 
> > @@ -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.

Oh yes, I'm just itching to introduce a 'virQEMUDriverPtr' type
and may well do it real soon.

> 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).


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|