On 30.10.20 06:33, Oliver Hartkopp wrote:
> Hi Vincent,
>
> On 24.10.20 15:00, Oliver Hartkopp wrote:
>> On 24.10.20 14:00, Vincent MAILHOL wrote:
>
>>> * Set up two channels can0 and can1 and connected those to the same
>>> bus.
>>>
>>> * Ran 'cangen can0' and 'candump any' simultaneously.
>>>
>>>
>>> Results of candump:
>>> can0 539 [8] 05 21 8C 5C F7 B0 7C 69
>>> can1 539 [8] 05 21 8C 5C F7 B0 7C 69
>>> can0 47E [1] 53
>>> can1 47E [1] 53
>>> can0 317 [6] E5 00 B5 73 66 CF
>>> can1 317 [6] E5 00 B5 73 66 CF
>>> can0 524 [E] 64 C3 B0 6E 55 7A D7 2E
>>> can1 524 [E] 64 C3 B0 6E 55 7A D7 2E
>>> can0 39C [D] 63 18 96 69 F6 7A AB 36
>>> can1 39C [D] 63 18 96 69 F6 7A AB 36
>>> can0 60D [F] F2 C6 B6 1D 80 FB BC 7E
>>> can1 60D [F] F2 C6 B6 1D 80 FB BC 7E
>>> can0 5DD [9] 7E 55 56 5B C0 23 B0 53
>>> can1 5DD [9] 7E 55 56 5B C0 23 B0 53
>>> can0 573 [E] 20 8E A3 31 1B 54 B2 16
>>> can1 573 [E] 20 8E A3 31 1B 54 B2 16
>>> can0 470 [3] 31 9C 06
>>> can1 470 [3] 31 9C 06
>>> can0 465 [4] 93 75 A2 08
>>> can1 465 [4] 93 75 A2 08
>>>
>>>
>>> Works fine :-)
>
> I'm not really sure about the view of Classical CAN DLCs in this 'long'
> candump representation.
>
> There are people that use this format as base for further processing -
> instead of the logfile format m(
> So it may be a bad decision to put the DLC value in the length position
> here.
There was actually zero thought when I wrote this. I just wanted to
test the kernel land and this was the first hack which came to my
mind.
candump is not an easy one to modify. When putting the DLC in the
picture, I can see three option:
1. Do not modify the format. Nothing will break but it would be
impossible to know the actual DLC value of a Classical CAN frame
of length 8.
2. Ask people doing processing on the candump output to modify their
tool if they want to use the cc-len8-dlc switch (if not using it,
should not break).
3. The in-between solution: use a command line switch (e.g. candump
-8 any) select option 1 or 2 at run time.
None of the solution is perfect.
I personally do not like option 3. So far, the command "candump any"
would capture all the information. For example, their is no switch to
enable/disable the capture of CAN-FD frames so it would seems odd to
me to have it only for the DLC.
Option 1 would be inconvenient for people who have needs similar to
mine. Option 2 would be inconvenient for people who want to use
cc-len8-dlc but do not want to touch their tools built on top of
candump.
At the end of the day, I can not think of a perfect solution but I
actually liked your previous idea of using parenthesis. The rule would
be that [x] would designate a DLC of len2dlc(x) and a length of x; and
(x) would designate a DLC of x and length of 8. On a security point of
view, I think that the impact would be minimal. If we change the
format form [x] to (x), parsing tools build on top should directly
crash and the user should notice directly.
> I changed the logfile format in a backward compatible way and therefore
> the cansend command line format too:
>
> (1604004658.444168) vcan0 2C0##02643
> (1604004658.494492) vcan0 615#R8_9
> (1604004658.645395) vcan0 6FF#
> (1604004658.695682) vcan0 623##318F88F7043C0
> (1604004658.746046) vcan0 63A##28D1F37
> (1604004658.796214) vcan0 1117DEA5##0BC281D711098
> (1604004658.846397) vcan0 1490B893#R8_F
> (1604004658.896585) vcan0 1F494EC8##39C47E2
> (1604004658.947142) vcan0 1D1EC448#3DC1C81345D7ED7E_D
> (1604004658.997689) vcan0 1C8661BB##14DEA7568D459160D
> (1604004659.047851) vcan0 2D8#AFE0546E6522130D_E
> (1604004659.098216) vcan0 1596E833##3E6789514EF10B466E6789514EF10B466
Not the most sexy solution but I have to admit that it does the job
and fits well with the other tools. Also, I am not able to think of a
better solutions.
Not sure if anyone also uses this log format as base for further
processing. Somewhere, someone might be impacted as well. But there is
probably nothing that we can do about that.
> My can-utils len8_dlc test setup is here:
> https://github.com/hartkopp/can-utils
>
> Feel free to do some tests, e.g. with cangen, candump, canplayer.
> Feedback is appreciated.
Sorry for the late feedback. I applied all the changes on the user
land and just started the tests. First results are good :)
So far, I found a minor issue in cangen.c, will send you a patch in an
other email right after.
I will need more time to complete a full test and review.
Overall, I think that you did a good job in the naming convention and
the choice of the command line options.
Thanks a lot!
Yours sincerely,
Vincent Mailhol
