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

[Eric Blake]

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

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


> -static int qemudGetMaxVCPUs(virConnectPtr conn ATTRIBUTE_UNUSED,
> const char *type) {
> +static int qemuGetMaxVCPUs(virConnectPtr conn ATTRIBUTE_UNUSED,
> const char *type) {

'{' should be on its own line (saving that for a separate cleanup
patch would be okay though).

>      if (!type)
>          return 16;
>  
> @@ -1246,7 +1246,7 @@ static int qemudGetMaxVCPUs(virConnectPtr conn
> ATTRIBUTE_UNUSED, const char *typ
>  }
>  
>  
> -static char *qemudGetCapabilities(virConnectPtr conn) {
> +static char *qemuGetCapabilities(virConnectPtr conn) {

And again.

> @@ -2587,39 +2587,42 @@ cleanup:
>  }
>  
>  
> -#define QEMUD_SAVE_MAGIC   "LibvirtQemudSave"
> -#define QEMUD_SAVE_PARTIAL "LibvirtQemudPart"
> -#define QEMUD_SAVE_VERSION 2
> +/* It would be nice to replace 'Qemud' with 'Qemu' but
> + * this magic string is ABI, so it can't be changed
> + */
> +#define QEMU_SAVE_MAGIC   "LibvirtQemudSave"
> +#define QEMU_SAVE_PARTIAL "LibvirtQemudPart"
> +#define QEMU_SAVE_VERSION 2

Aha - there's the three added lines.  And I concur; 'virsh restore'
would break if we altered this string.

> -enum qemud_save_formats {
> -    QEMUD_SAVE_FORMAT_RAW = 0,
> -    QEMUD_SAVE_FORMAT_GZIP = 1,
> -    QEMUD_SAVE_FORMAT_BZIP2 = 2,
> +enum qemu_save_formats {

While touching this, should we name it qemuSaveFormats?  (That is,
either here or in a followup, shouldn't enum types be camel-cased?)

> +    QEMU_SAVE_FORMAT_RAW = 0,
> +    QEMU_SAVE_FORMAT_GZIP = 1,
> +    QEMU_SAVE_FORMAT_BZIP2 = 2,
>      /*
>       * Deprecated by xz and never used as part of a release
> -     * QEMUD_SAVE_FORMAT_LZMA
> +     * QEMU_SAVE_FORMAT_LZMA
>       */

At this point, we could delete this comment altogether.

> @@ -2628,7 +2631,7 @@ struct qemud_save_header {
>  };
>  
>  static inline void
> -bswap_header(struct qemud_save_header *hdr) {
> +bswap_header(struct qemu_save_header *hdr) {

Should we be renaming this helper function into
qemuBswapHeader?

>      hdr->version = bswap_32(hdr->version);
>      hdr->xml_len = bswap_32(hdr->xml_len);
>      hdr->was_running = bswap_32(hdr->was_running);
> @@ -2639,7 +2642,7 @@ bswap_header(struct qemud_save_header *hdr) {
>  /* return -errno on failure, or 0 on success */
>  static int
>  qemuDomainSaveHeader(int fd, const char *path, const char *xml,
> -                     struct qemud_save_header *header)
> +                     struct qemu_save_header *header)

Another annoying struct name, where a typedef'd qemuSaveHeaderPtr
would be nicer.  But again, save it for a followup 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).