Re: [RFC] K-Line protocol via SocketCAN

[Marek Vasut <marex@denx.de>]

On 06/14/2016 08:10 AM, Oliver Hartkopp wrote:
> 
>>> On 06/11/2016 09:42 PM, Marek Vasut wrote:
>>>> Well, I was talking about arinc 429 .
>>>>
>>>
>>> Ah - I remember that discussion:
>>> https://lwn.net/Articles/663130/
>>> http://thread.gmane.org/gmane.linux.network/385449
>>>
>>> What happed to it?
>>
>> Priorities shifted. I still hope to return to it and get it into
>> mainline proper. Since I did some digging in the socketcan recently,
>> I have a better understanding of it now too. I believe the agreement
>> there was to put it into the socketcan stack as an extension, does it
>> still make sense ?
>>
> 
> There were intensive discussions about the original patchset and I think
> the copy&paste hell from the PF_CAN won't make it.

Yeah, that's pretty clear to me. But does it make sense to extend
socketcan with that arinc429 stuff instead then ?

> Let's see how the K-Line discussion opens your view :-)

Well it certainly was enlightening.

> (..)
> 
>>> E.g. think about a chardev in /dev/kline0 which is located in
>>> linux/drivers/misc and which uses a tty under the hood.
>>>
>>> I'm not a K-Line specialist like Mirza who was able to point at timings
>>> that should be handled in user space and not in kernel space.
>>
>> If I start handling the timings in userspace, I won't be able to get to
>> the precision I need. That's the reason I'd like to put the kline ldisc
>> in kernel.
>>
>>> But if you implement a chardev driver which allows the configuration of
>>> these kernel relevant K-Line timings and makes use of the tty layer -
>>> what should be wrong with this approach?
>>>
>>> You would have a single user K-Line interface which can handle specific
>>> struct kline data. Fine.
>>
>> Hrm. I was just worried about adding new IOCTLs, but if that's fine, I
>> will reevaluate using just the ldisc.
>>
> 
> Putting the really necessary timing requirements into the kernel into
> the ldisc need some configuration of that ldisc. AFAIK ldisc specific
> ioctls are the way to configure that kind of details.
> 
> So let's see what happens when you post it.

Right.

>>>>> 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 ?
>>>
>>> Yes. It would be some kind of ldisc for a K-Line chardev driver (and not
>>> for a netdevice) like other ldiscs in linux/include/uapi/linux/tty.h
>>>
>>> Why do you feel this is not a good idea?
>>
>> It feels much better now, so I will poke into that.
> 
> Thanks!

Thanks!


-- 
Best regards,
Marek Vasut