Re: [RFC] CAN FD support

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 03.05.2012 15:00, Kurt Van Dijck wrote:

>>
>> Furthermore, the user should be allowed to specify *any* lenght below
>> max, als 57 bytes. It's than up to the driver to do the necessary padding.
> I think Oliver solved this (on af_can level?) with a table len2dlc (static in the header?)


Yes - it was the only way not to make it clash when linking proc.o and
af_can.o together.

Btw. if we move this functionality to the driver, i would like to move it from
can.h into dev.c :-)

> 
>>
>>>
>>> What about this binary compatible introduction of cf->len ...
>>
>> Looks good.
> Yep, given 2 structs, this illustrates the contents very well!


Fine.

One question:

What about omitting the union in struct can_frame modification and leave it as
it is since the first days of SocketCAN?

We can still check these offsets

 	BUILD_BUG_ON(offsetof(struct can_frame, can_dlc) !=
-		     offsetof(struct canfd_frame, can_dlc));
+		     offsetof(struct canfd_frame, len));


and can (kernel) internally use struct canfd_frame as reference:

	struct canfd_frame *cfd = (struct canfd_frame *)skb->data;
	struct net_device_stats *stats = &dev->stats;

	stats->rx_packets++;
	stats->rx_bytes += cfd->len;

which would cover cf->can_dlc in the same way.

I wonder, if people would start to use can_frame.len once it is defined as
this would not be backward compatible code (but binary compatible).

Regards,
Oliver