Re: [RFC] K-Line protocol via SocketCAN

[Oliver Hartkopp <socketcan@hartkopp.net>]

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

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

(..)

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

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

Oliver