[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: compat code lacks support for __attribute__


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Olaf Hering <olaf@xxxxxxxxx>
  • Date: Fri, 16 Jun 2023 11:51:03 +0200
  • Arc-authentication-results: i=1; strato.com; arc=none; dkim=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1686909070; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Cc:Date: From:Subject:Sender; bh=2P1x9GXm0TweywT8hh6nU0PzG0yD9qJ7KPg+jyEgi9o=; b=V3JWGl8eHeEupf/GKSR21jKGHKTr+TWOud5FGYH+OSu0NVh+bVO12jSZNCqK+qJb40 l1PmZXa8zG+Wdw/m7gOrN/DO+x8f28LdC+q/W8HC32w9+zabpPaArpbCWEhYnhBZG2Br KZ7Jr1rXoKhWOlgLPrl3OmUkyPAcuYnIiRbMi0/7XhyKqA2jPsabNfk+D7IjCQcVQQtq wFDgmDGlaHbULVhBEVdONZgYrZLcde7x439/TUvaB8WYIj57XX0jGKxtAdnRFEdLFvqi IJvmv6D99E/3ibaMI69eMapG5CLD9F+BKH3Aq3UwPFbTLwmULLdH5pwTxMdG+3ewa0Lf MJRA==
  • Arc-seal: i=1; a=rsa-sha256; t=1686909070; cv=none; d=strato.com; s=strato-dkim-0002; b=J+fcPpGIMbsH1BcD4udFSFWiCiKkK6T20RjtjFyiUCMESNju7GogjT3mIG2Oyc7/IC hqQlyLM+1pz/W4HhjGNpnllRX43QUWkZS7pL+jGkKFKcsCwF47xYWqGaVAh/1FoEFrJi p/XdGgq/LvGCzanSdumzoJ88Ud9RHWyPnkbicgxj/nzPC6Tlu1sRbDz24IaE9qImB5o7 hQUhfV6kniGJs1WIGdg3ZLlFFcIW6lGJT+M/pyJW4MFtW4qJT1lwTum+tLKZEQEIhKil OQOMQ4W5i7dfHeEQHh0UbZRRFYlCwNgqGygWoDEvJaly8gF4VKNRvcNh1ZL1E8Y+q5e0 gQYA==
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 16 Jun 2023 09:51:35 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Wed, 14 Jun 2023 11:49:35 +0200 Jan Beulich <jbeulich@xxxxxxxx>:

> However, if you're after adding packed attributes, and if you're
> meaning to only communicate between Xen and the tool stack, then
> the requirement above doesn't exist. Yet then I would also wonder
> whether you need any compat translation in the first place. Those
> packed structures would better be arch-/bitness-agnostic, wouldn't
> they? So perhaps we could arrange for your additions to be excluded
> from the compat translation machinery?

The change below works for me. I wonder if any special compat handling
for t_buf and t_rec is required. To me it looks like only uint32_t is
used, which will most likely cause no unexpected alignment issues.


Olaf

--- a/xen/common/trace.c
+++ b/xen/common/trace.c
@@ -34,15 +34,6 @@
 #include <asm/atomic.h>
 #include <public/sysctl.h>
 
-#ifdef CONFIG_COMPAT
-#include <compat/trace.h>
-#define xen_t_buf t_buf
-CHECK_t_buf;
-#undef xen_t_buf
-#else
-#define compat_t_rec t_rec
-#endif
-
 /* opt_tbuf_size: trace buffer size (in pages) for each cpu */
 static unsigned int opt_tbuf_size;
 static unsigned int opt_tevt_mask;
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -30,7 +30,7 @@ headers-$(CONFIG_HVM)     += compat/hvm/hvm_op.h
 headers-$(CONFIG_HVM)     += compat/hvm/hvm_vcpu.h
 headers-$(CONFIG_HYPFS)   += compat/hypfs.h
 headers-$(CONFIG_KEXEC)   += compat/kexec.h
-headers-$(CONFIG_TRACEBUFFER) += compat/trace.h
+headers-n                 += compat/trace.h
 headers-$(CONFIG_XENOPROF) += compat/xenoprof.h
 headers-$(CONFIG_XSM_FLASK) += compat/xsm/flask_op.h
 
--- a/xen/include/public/trace.h
+++ b/xen/include/public/trace.h
@@ -81,6 +81,15 @@
 #define TRC_TRACE_WRAP_BUFFER  (TRC_GEN + 2)
 #define TRC_TRACE_CPU_CHANGE    (TRC_GEN + 3)
 
+#define TRC_a (TRC_GEN + 123)
+struct __attribute__((__packed__)) trc_a {
+    unsigned a;
+};
+#define TRC_b (TRC_GEN + 321)
+typedef struct __attribute__((__packed__)) trc_b {
+    unsigned b;
+} trc_b_t;
+
 #define TRC_SCHED_RUNSTATE_CHANGE   (TRC_SCHED_MIN + 1)
 #define TRC_SCHED_CONTINUE_RUNNING  (TRC_SCHED_MIN + 2)
 #define TRC_SCHED_DOM_ADD        (TRC_SCHED_VERBOSE +  1)

Attachment: pgpOMAQGS8AG_.pgp
Description: Digitale Signatur von OpenPGP


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.