On 28/03/2025 7:49 am, Jan Beulich wrote: > On 27.03.2025 18:33, Oleksii Kurochko wrote: >> BITS_PER_* values can be defined in a common way using compiler-provided >> macros. >> Thus, these definitions are moved to xen/config.h to reduce duplication >> across >> architectures. >> >> Additionally, *_BYTEORDER macros are removed, as BITS_PER_* values now come >> directly from the compiler environment. >> >> The arch_fls() implementation for Arm and PPC is updated to use BITS_PER_INT >> instead of a hardcoded value of 32. >> >> Suggested-by: Andrew Cooper <andrew.coop...@citrix.com> >> Signed-off-by: Oleksii Kurochko <oleksii.kuroc...@gmail.com> > Reviewed-by: Jan Beulich <jbeul...@suse.com> > albeit ... > >> --- a/xen/include/xen/config.h >> +++ b/xen/include/xen/config.h >> @@ -98,4 +98,14 @@ >> #define ZERO_BLOCK_PTR ((void *)-1L) >> #endif >> >> +#define BYTES_PER_LONG __SIZEOF_LONG__ > ... I remain unconvinced that we actually need this (yet then not its sibling > for int). All uses I can spot could be replaced by sizeof(long).
Perhaps, but that's orthogonal to centralising the definition. It can be deferred. > This (and its > sibling) would be needed only for #if uses, and there I would then wonder why > we couldn't use __SIZEOF_LONG__ directly, now that we assume its universally > available. Looking at the usages, sizeof(long) would be best, and shortest. While we do have a whole bunch of constants which are universally available now, I still want to use the more normal terms where possible. e.g. the difference between __BYTE_ORDER__ and BYTE_ORDER is relevant for the code shared with userspace, and using BYTE_ORDER across Xen is the cleaner option. ~Andrew
