Re: [RFC] K-Line protocol via SocketCAN

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 06/01/2016 04:26 AM, Marek Vasut wrote:

>>> What would be the advantages to put this into kernel space (or into the
>>> CAN networking infrastructure)?
>>
>> I see two for putting this into the kernel:
>> - At faster bus speeds, you can achieve more precise timing if this is
>>    in the kernel, both of the inter-byte delay and also for the
>>    timestamps. Having this in the kernel even allows usage of the
>>    realtime extensions if needed.

A topic for the serial driver infrastructure?

>> - Dedicated hardware driver can plug into such K-Line infrastructure.
>>    Such hardware might be needed to support the faster modes to further
>>    increase the timing precision.

Which K-Line infrastructure?

>> And two for using socketcan/network interface:
>> - The addressing support of the network stack can be mapped to K-Line
>>    bus addresses.

The K-Line addressing is totally different from CAN addressing. Why do 
you think the stuff in linux/net/can has any conjunction to K-Line 
addressing?

>> - The rtnl can be used as an extensible interface for configuring the
>>    K-Line parameters.

The idea of SocketCAN using the Linux networking infrastructure and 
network interfaces is the multi-user capability which is enabled through 
this layering.

IIRC K-Line is ONE point-to-point connection which is not multi-user 
capable - so what would be the benefit to implement a K-Line serial 
driver as network device and then configure it via rtnl?

> What do you think about putting the KLine support into socketcan stack ?

If I would think about your mentioned requirements and ideas I would 
start with pyOBD http://www.obdtester.com/pyobd and probably move this 
to be a PREEMPT_RT task and I would add an interface to specify 
inter-byte delays into the serial driver infrastructure.

Even when trying to think very positively about your question I don't 
see any conjunction to SocketCAN.

Best regards,
Oliver