Re: [RFC] CAN FD support

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 03.05.2012 15:44, Marc Kleine-Budde wrote:

> On 05/03/2012 02:38 PM, Oliver Hartkopp wrote:
> [...]
> 
>>> I share this.
>>> I'd even prefer u16 over u8 even.
>>> No legacy issues exist when changing the meaning of can_dlc, since current
>>> CAN frames have equal values for DLC & length!
>>>
>>>> the struct is also used by the app.
>>
>>
>> Yes - that's the main problem IMO.
>>
>> What about this binary compatible introduction of cf->len ...
> 
> ...but it's not 100% source compatible, due to a compiler bug in gcc.
> You cannot use C99 initializers on anonymous unions in certain gcc versions.


ugh!

> 
> [..]
> 
>> --- a/include/linux/can.h
>> +++ b/include/linux/can.h
>> @@ -57,7 +57,10 @@ typedef __u32 can_err_mask_t;
>>   */
>>  struct can_frame {
>>  	canid_t can_id;  /* 32 bit CAN_ID + EFF/RTR/ERR flags */
>> -	__u8    can_dlc; /* data length code: 0 .. 8 */
>> +	union {
>> +		__u8    can_dlc; /* data length code: 0 .. 8 */
>> +		__u8    len; /* data length: 0 .. 8 */
>> +	};
>>  	__u8    data[8] __attribute__((aligned(8)));
>>  };
> 


Thanks for the hint.

Indeed i left the struct can_frame as is now!

There's now can_frame.can_dlc and canfd_frame.len which both contains the real
length - even if can_frame.can_dlc is literally a data length *code* .

Btw. by having canfd_frame.len we indicate for CAN FD that we have a real
length here.

Regards,
Oliver