Re: [RFC] can: Introducing CANFD for af_can & can-raw

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 22.03.2012 12:00, Wolfgang Grandegger wrote:

> On 03/22/2012 11:35 AM, Kurt Van Dijck wrote:

>> The remaining 1% may or may not work. In case of proper coded programs,
>> I'm sure they work. In other cases, I'm not sure.
>> Thus the question is:
>> Does the remaining 1% that we don't know, justify an alternate approach?


Yes it does. As pointed out yesterday breaking ABI is a no go.
I won't like to come into focus with Linus discussing a pointless ABI item.

> Well, I do not yet know. I first would like to see the data sheet of a
> CANFD controller to understand better the possible use cases. And
> without real use case, we will not add any CANFD support to the mainline
> kernel anyway. There is still some time to think and discuss.


That's also my impression.

> 
>> My initial patch mainly illustrates that this may be a reasonable question.
>>
>> As ethernet user, on a socket level, I also do not care about low-level
>> technology (100Mbit, 1GBit, UTP, ...).
> 
> But that's because we use higher-level protocols like UDP and TCP which
> do not care about the hardware frame size.


Indeed this is what i wanted to express, when writing this:

When there's a defined socket API that makes use of struct can_frame (like
can_raw, can_bcm, can_gw - but not isotp! \o/ ) we need to

- duplicate the socket API - like CAN_RAWFD (ugly)
- switch the frame size (e.g. via sockopt)
- a third unknown idea ...

ISOTP is off this discussion as it does not deal with struct can_frame.

Any other of the CAN protocol definitions does.

Regards,
Oliver