On 28.07.2020 12:15, Andrew Cooper wrote:
The Xen domctl ABI currently relies on the union containing a field with
alignment of 8.
32bit projects which only copy the used subset of functionality end up with an
ABI breakage if they don't have at least one uint64_aligned_t field copied.
I'm entirely find with the change, but I'm struggling with this justification:
How can _any_ change to the header in our tree help people using custom
derivations (i.e. including those defining only some of the union members)?
Further proof that C isn't an appropriate way to desribe an ABI...
Further proof that it requires more careful writing in C to serve as an ABI
description, I would say.
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -959,6 +959,14 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
u_domctl)
return ret;
}
+static void __init __maybe_unused build_assertions(void)
+{
+ struct xen_domctl d;
Doesn't this also need __maybe_unused? Afaik ...
+ BUILD_BUG_ON(sizeof(d) != 16 /* header */ + 128 /* union */);
+ BUILD_BUG_ON(offsetof(typeof(d), u) != 16);
+}
... neither sizeof() nor typeof() count as actual uses.
Jan
