Re: [PATCH 1/2] conf: Turn @uuid member of _virDomainMemoryDef struct into a pointer
On Mon, Jan 18, 2021 at 15:15:53 +0100, Michal Privoznik wrote:
The _virDomainMemoryDef structure has @uuid member which is
needed for PPC64 guests. No other architectures use it. Since the
member is VIR_UUID_BUFLEN bytes long, the structure is
unnecessary big. If the member is just a pointer then we can also
Umm, this saves just 8 bytes. (pointer is 8, VIR_UUID_BUFLEN 16)
replace some calls of virUUIDIsValid() with plain test against
NULL.
This commit isn't replacing them though (which is okay), but it also
moves logic out of the XML formatter where we no longer need to check
for the correct architecture, which isn't mentioned.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/conf/domain_conf.c | 14 ++++++++------
src/conf/domain_conf.h | 2 +-
src/qemu/qemu_command.c | 2 +-
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index ff3b7cbfc8..a2ddfcf947 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
[...]
@@ -22808,7 +22810,9 @@
virDomainMemoryDefCheckABIStability(virDomainMemoryDefPtr src,
return false;
}
- if (memcmp(src->uuid, dst->uuid, VIR_UUID_BUFLEN) != 0) {
+ if ((src->uuid || dst->uuid) &&
+ !(src->uuid && dst->uuid &&
+ memcmp(src->uuid, dst->uuid, VIR_UUID_BUFLEN) == 0)) {
wrong alignment of the memcmp line since it's inside the second
sub-term.
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
"%s",
_("Target NVDIMM UUID doesn't match source
NVDIMM"));
return false;
[...]
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index f59d972c85..6645282bf6 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -2331,7 +2331,7 @@ struct _virDomainMemoryDef {
bool readonly; /* valid only for NVDIMM */
/* required for QEMU NVDIMM ppc64 support */
- unsigned char uuid[VIR_UUID_BUFLEN];
+ unsigned char *uuid;
Please add a comment that this is expected to be VIR_UUID_BUFLEN long
buffer if allocated.
virDomainDeviceInfo info;
};
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>