Re: can-j1939 API

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 30.10.2015 00:38, Kurt Van Dijck wrote:
>> From: Oliver Hartkopp <socketcan@hartkopp.net>
>> To: Alex Layton <alex@layton.in>, Kurt Van Dijck

>>> Yep, I can follow that argument.
>>> When I get to it, I'll change that.
>>> It also implies I can drop iproute2-j1939 branches completely.
>>>
>>
>> Just to be sure I understood it correctly:
>>
>> No iproute2-j1939 branch -> no address support for j1939 in iproute
>> -> no address support in af_can.c ?? \o/
>
> indeed.
> Next to the address support, I also would then drop the link status
> support (i.e. ip link set can0 j1939 on/off).

ok

>> So you would automatically take care of SA/Name when a j1939 socket is created
>> with the according address information (== per-socket), right?
>
> All SA or Name info comes via that way, indeed.
> Any can-j1939 socket (regardless the user) could bind to a new SA or Name.

This is what I would expect :-)

As Alex is only using SA in his implementation: Is the name still mandatory as 
j1939 address information?

> 'per socket' is a bit dubious. In contrast to Alex, I would not restrict
> a specific SA or Name to a single socket for reasons I gave earlier.

If I understand you correctly the first socket which is giving his address 
information enables the j1939 address (claiming) handling inside the Kernel, 
right?

Btw. is it possible to create two processes on the same Linux box which 
implement two different j1939 nodes (e.g. engine and trailer) that can 
communicate with each other both using the *same* CAN interface (can0 or vcan0)??

Regards,
Oliver