Hi Vincent,
On 11.09.22 09:50, Vincent Mailhol wrote:
On Thu. 8 Sep. 2022 at 16:24, Oliver Hartkopp <socketcan@xxxxxxxxxxxx> wrote:
(..)
The CAN-ID was (due to its arbitration nature) always also a priority
field.
The CAN-(FD) ID holds two roles: priority and ID. For CAN XL, it is
only ID.
Typo? It is only the priority ;-)
While I agree that both have the priority attributes, my
concerns are on the semantics. The type is canid_t, not canprio_t. I
just want to point that it is weird to had ID in the type when that
field doesn't have an ID property anymore.
CAN XL moves away from the two roles combined in the CAN(FD) Identifier.
The main focus is on arbitration now (CAN XL is like CAN arbitration
with Ethernet data).
But in the end the CAN bitstream at the beginning of the frame including
the arbitration is completely identical for all CAN variants.
Even when this arbitration field is now named priority for CAN XL it is
still the exact mechanism of the CAN identifier (what we introduces
canid_t for).
Therefore having canid_t for can_id and prio seems appropriate.
So nothing changed here. There is no RTR and no 29-bit priority anymore
now. The RTR flag has already been disabled for CAN FD (see presentation
at the end of this mail).
Therefore it makes sense to handle the SFF 11-bit prio analogue to the
former CAN-ID - and also use canid_t to simply keep the entire CAN
filter handling in af_can.c !
This is a good argument to keep using the canid_t. If we make it a
u16, we lose the alignment (unless we add dirty endianness
preprocessing macros).
Yep.
(..)
Btw. I uploaded a presentation which shows the way from classical CAN to
CAN XL which might depict some relations of the bits in a clearer way:
https://github.com/linux-can/can-doc/blob/master/presentations/CAN-XL-Intro.pdf
Thanks. With the Bosch PDF now returning error 404, I suggest
replacing the link in the cover letter with your link (or the CIA
knowledge page).
Ok, will do.
Best regards,
Oliver
