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@xxxxxxxxxx>
> > ---
> > 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 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list