Re: [RFC] K-Line protocol via SocketCAN

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 06/09/2016 09:21 PM, Marek Vasut wrote:
> On 06/09/2016 08:29 PM, Oliver Hartkopp wrote:

>>> I am more interested in the RTNL configuration interface, since the
>>> kline has way too many parameters and the RTNL scales well in that
>>> aspect.
>>
>> If like rtnl so much why don't you create a K-Line netdevice driver for
>> it and use the PF_PACKET socket to exchange data with the netdevice?
>
> Because last time I did that with the arinc, I was told to integrate
> that into the socketcan instead.
>
>>> When using the socket interface, I can also add various flags to the
>>> packet and control the properties of the data that are to be transmitted
>>> via the KLine interface. That's real convenient.
>>
>> But that has nothing to do with PF_CAN.
>
> So I should add another orthogonal infrastructure ? That's what I did
> with the arinc and I was told the exact opposite, so I am really
> confused here .

ARINC 825 *is* CAN. When people tell you to use the existing 
infrastructure that was a good hint, but K-Line is definitely not CAN.

Your patch set shows that you are adding things to the CAN 
infrastructure that have nothing to do with CAN.

E.g. the K-Line timing you add in patch 4/5 has nothing to do with CAN 
specific configurations.

Additionally I don't know whether the struct kline_frame is the optimal 
solution because it sticks to struct can_frame and does not reflect the 
(optional) K-Line address scheme.

So you could either use the sl_kline.c with PF_PACKET and create a 
separate rtnl configuration for it OR you could create a character 
device which handles K-Line frames and has some ioctls to configure the 
specialized timings.

As K-Line never was multi-user capable by design the chardev approach is 
the most 'natural' concept IMHO.

Regards,
Oliver