On 23.07.22 04:39, Vincent Mailhol wrote:
This debate is going to a dead end. I do not see one of us fully
convincing the other. As I stated before, the data[CANXL_MIN_DLEN] is
not bad and has the big merit of allowing static declaration. While my
preference definitely goes to the flexible array member, I will not
veto your idea. I think it was important to have this debate.
With that said, I leave the final decision to the mailing list. If
other people prefer the data[CANXL_MIN_DLEN] over the flexible array
member, or if no one other than the two of us care, then let's use
your approach!
Thanks Vincent!
I really think it is the right approach to maintain the current CAN_RAW
API patterns for all CAN flavours. It provides consistency for
programmers and tools and really only affects the CAN_RAW socket.
When it comes to Ethernet traffic encapsulation inside CAN XL this can
be seen as a break to the CAN stuff and I wonder if we should create
another 'Ethernet like' network device then.
E.g. an Ethernet device, that is able to handle/convert ETH_P_CANXL
frames and offers additional attributes (setting the prio and defining
the CAN XL encapsulation schema etc). This will kick us into the
Ethernet world with all the common APIs - and will definitely fuel a new
and interesting discussion ;-)
Best regards,
Oliver
