On 15.07.22 10:28, Vincent Mailhol wrote:
On Fri. 15 Jul. 2022 at 15:51, Oliver Hartkopp <socketcan@xxxxxxxxxxxx> wrote:
But then you would have to name it struct canxlhdr or canxl_hdr to
follow this pattern, right?
And this is my other problem. The struct canxl_frame should be able to
contain a CAN XL frame (as can[fd]_frame do).
I'm fine with introducing e.g. a
struct canxl_hdr {
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[];
};
and propose the suggested use-patterns.
No, you misunderstood my comment. The ipdhr and tcphdr was to
illustrate the fact that it is not uncommon to build some data
structure on your own. In those two examples, the hdr suffix is used
because there is no payload (i.e. no data field in the struct).
In our case, it would be:
struct canxl_hdr {
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 */
};
struct canxl {
struct canxl_hdr hdr;
__u8 data[];
}
Which is equivalent to:
struct canxl {
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[];
};
Unfortunately not really.
You have the same memory layout but you can access the content in a
different way:
struct canxl cxl1; (the first one)
cxl1.hdr.flags
struct canxl cxl2; (the second one)
cxl2.flags
:-/
It would be cool to handle and define
struct canxl_hdr
that could be used in
struct canxl_frame (containing data[2048])
and
struct canxl_msg (containing data[])
But this might confuse programmers even more.
Regards,
Oliver
