On 12.02.24 10:34, Guy Harris wrote:
On Feb 12, 2024, at 1:21 AM, Guy Harris <gharris@xxxxxxxxx> wrote:
How many processors - as in "number of CPUs", not "number of instruction set architectures" - capturing CANbus traffic and producing SocketCAN headers are big-endian, and how many are little-endian?
To be more specific, how many processors - as in "number of CPUs", not "number of instruction set architectures" - capturing *CAN XL* traffic and producing SocketCAN headers are big-endian, and how many are little-endian?
I assume only ARM(64), X64 and Risc-V architectures will get in contact
with CAN XL. And all these archs are little-endian.
I only had the data structure example in big-endian to increase the
readability.
The currently discussed struct canxl_frame is here:
https://lore.kernel.org/linux-can/20240128183758.68401-1-socketcan@xxxxxxxxxxxx/
struct canxl_frame {
#if defined(__LITTLE_ENDIAN)
__u16 prio; /* 11 bit priority for arbitration */
__u8 vcid; /* virtual CAN network identifier */
__u8 __res0; /* reserved / padding must be set to zero */
#elif defined(__BIG_ENDIAN)
__u8 __res0; /* reserved / padding must be set to zero */
__u8 vcid; /* virtual CAN network identifier */
__u16 prio; /* 11 bit priority for arbitration */
#else
#error "Unknown endianness"
#endif
__u8 flags; /* additional flags for CAN XL */
__u8 sdt; /* SDU (service data unit) type */
__u16 len; /* frame payload length in byte */
__u32 af; /* acceptance field */
__u8 data[CANXL_MAX_DLEN];
};
To maintain the filtering of the 11 bit CAN identifier (inside the
uint32 canid_t in Classical CAN and CAN FD) the 11 bit PRIO value has to
share the position of these 11 bits.
Therefore the somewhat ugly endian handling is to be introduced.
Or would you suggest to generally add the vcid content into the uint32
space by shifting and masking, like in this previous suggested patch?
https://lore.kernel.org/linux-can/20240106192836.4716-1-socketcan@xxxxxxxxxxxx/
Best regards,
Oliver