Re: [RFC] K-Line protocol via SocketCAN

[Marek Vasut <marex@denx.de>]

On 06/09/2016 10:12 PM, Oliver Hartkopp wrote:
> 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.

Well, I was talking about arinc 429 .

> 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.

Is adding a specialized chardev really such a great idea ?

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

I could technically just implement this as a ldisc with some additional
ioctls, but is that really such a good idea ?

> Regards,
> Oliver
> 


-- 
Best regards,
Marek Vasut