On 21.07.22 10:14, Vincent Mailhol wrote:
On Thu. 21 Jul. 2022 at 16:53, Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx> wrote:
On 21.07.2022 09:36:21, Oliver Hartkopp wrote:
Btw. How should we finally name the 'non data' header of CAN XL?
1. CANXL_HEADER_SIZE
2. CANXL_HEAD_SIZE
3. CANXL_HDR_SIZE
4. CANXL_HDR_SZ <- currently in the patches
5. CANXL_HD_SZ
I think it has to be 'head' and not 'header'.
Header! Header is in front of data.
I am also part of the header team! By analogy with:
https://en.wikipedia.org/wiki/IPv4#Header
In skbs we also have head and tail.
Yes, but they point at the head or tail of the buffer allocated with the
skb.
So I would vote for 2 or 5 with a tendency to 5.
3, 1, 4
My top vote goes to:
6. No macro, instead use flexible array member and do sizeof(struct canxl_frame)
This is no sizeof(struct canxl_frame) anymore with the use of a flexible
array because a valid "CAN XL frame" has data (at least one byte and up
to 2048 byte).
You might name it
struct canxl_header {
canid_t prio; /* 11 bit priority for arbitration (canid_t) */
__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[];
};
But then you can't build a struct canxl_frame anymore in the way that
you can access the elements as you can do it today:
struct canxl_frame {
struct canxl_header xldhr;
data[CANXL_MAX_DLEN];
};
struct canxl_frame cfx;
=> cfx.xlhdr.len
Which is not cfx.len anymore what is a known pattern from struct
can[fd]_frame from CAN application programmers and simple to use.
The only new thing is the possibility to handle a truncated data[]
section. That should be feasible to learn.
I do not like the SZ abbreviation either, so my next choices will be 3 then 1.
To recap: 6, 3, 1.
Then CANXL_HDR_SIZE wins :-)
Regards,
Oliver
