| Message ID | 20250328134427.874848-3-andrew.cooper3@citrix.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | xen: Centralise byteswap infrastructure | expand |
On 28.03.2025 14:44, Andrew Cooper wrote: > There is a singular user. It's unlikely we'll gain a big-endian build of Xen, > but it's far more unlikely that bitfields will differ from main endianness. Just one point: While endian-ness in general is dictated by hardware, endian- ness of bitfields is entirely a psABI thing, aiui. Hence tying both together (beyond the latter defaulting to the former) doesn't seem quite appropriate to me. > I'm tempted to simply drop the logic in maptrack_node. If any big-endian > build of Xen came along, that's probably the least of it's worries. As long as it's not obviously broken, I'd prefer to keep such. While it may not be a primary worry, it's still one less of all the worries then. Jan
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c index 6c77867f8cdd..d6886ee74847 100644 --- a/xen/common/grant_table.c +++ b/xen/common/grant_table.c @@ -979,12 +979,12 @@ static struct active_grant_entry *grant_map_exists(const struct domain *ld, union maptrack_node { struct { /* Radix tree slot pointers use two of the bits. */ -#ifdef __BIG_ENDIAN_BITFIELD +#ifdef __BIG_ENDIAN unsigned long _0 : 2; #endif unsigned long rd : BITS_PER_LONG / 2 - 1; unsigned long wr : BITS_PER_LONG / 2 - 1; -#ifndef __BIG_ENDIAN_BITFIELD +#ifndef __BIG_ENDIAN unsigned long _0 : 2; #endif } cnt; diff --git a/xen/include/xen/byteorder/big_endian.h b/xen/include/xen/byteorder/big_endian.h index ce395a17f64b..9cfb567d51d5 100644 --- a/xen/include/xen/byteorder/big_endian.h +++ b/xen/include/xen/byteorder/big_endian.h @@ -4,9 +4,6 @@ #ifndef __BIG_ENDIAN #define __BIG_ENDIAN 4321 #endif -#ifndef __BIG_ENDIAN_BITFIELD -#define __BIG_ENDIAN_BITFIELD -#endif #include <xen/types.h> #include <xen/byteorder/swab.h> diff --git a/xen/include/xen/byteorder/little_endian.h b/xen/include/xen/byteorder/little_endian.h index 8b118afba5e3..96c80eab2b12 100644 --- a/xen/include/xen/byteorder/little_endian.h +++ b/xen/include/xen/byteorder/little_endian.h @@ -4,9 +4,6 @@ #ifndef __LITTLE_ENDIAN #define __LITTLE_ENDIAN 1234 #endif -#ifndef __LITTLE_ENDIAN_BITFIELD -#define __LITTLE_ENDIAN_BITFIELD -#endif #include <xen/types.h> #include <xen/byteorder/swab.h>
There is a singular user. It's unlikely we'll gain a big-endian build of Xen, but it's far more unlikely that bitfields will differ from main endianness. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> --- CC: Anthony PERARD <anthony.perard@vates.tech> CC: Michal Orzel <michal.orzel@amd.com> CC: Jan Beulich <jbeulich@suse.com> CC: Julien Grall <julien@xen.org> CC: Roger Pau Monné <roger.pau@citrix.com> CC: Stefano Stabellini <sstabellini@kernel.org> CC: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com> CC: Bertrand Marquis <bertrand.marquis@arm.com> CC: Shawn Anastasio <sanastasio@raptorengineering.com> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com> CC: Daniel P. Smith <dpsmith@apertussolutions.com> CC: Lin Liu <lin.liu@citrix.com> I'm tempted to simply drop the logic in maptrack_node. If any big-endian build of Xen came along, that's probably the least of it's worries. v5: * New. --- xen/common/grant_table.c | 4 ++-- xen/include/xen/byteorder/big_endian.h | 3 --- xen/include/xen/byteorder/little_endian.h | 3 --- 3 files changed, 2 insertions(+), 8 deletions(-)