Hi Kurt,
On 25.04.19 11:24, Kurt Van Dijck wrote:
On wo, 24 apr 2019 09:50:18 +0200, laurent vaudoit wrote:
Kurt, i've found this branch on your github,
https://github.com/kurt-vd/linux/tree/j1939d-v4.9.10/net/can/j1939
shouldn't it be a good start for us?
This is already an iproute-less version, so it's API requires you to
change your usespace slightly already.
Given the recent developments, I still propose to take the
latest-and-greatest can-next, and backport it.
I can't evaluate if it's a big task anymore, but 4.9 is not that old,
I guess that no major changes happened that make backporting useless.
Oleksij, since you sit close on top of this, what do you think about
backporting possibility?
Hhm... as usual, git cherry-pick +/- some regressions. In best case it will just work.
Kurt
best regards
Laurent
On Tue, Apr 23, 2019 at 8:14 PM Kurt Van Dijck
<dev.kurt@xxxxxxxxxxxxxxxxxxxxxx> wrote:
On di, 23 apr 2019 17:23:14 +0200, laurent vaudoit wrote:
On Tue, Apr 23, 2019 at 7:23 AM Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx> wrote:
Hi,
Hi Oleksij,
On 19.04.19 10:41, laurent vaudoit wrote:
Hi all,
we are now moving from 3.10 to 4.9.88 kernel on our project.
I was wondering which J1939 impelmentation chose:
-the old one (we have allready used on 3.10) with iproute2 patched
(but it seems this version has not been updated since a long time
(kernel 4.0.0?)
this variant will never change, it is all about you to fix and maintaine it.
-or the new one which is on can-next branch
(https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git/log/?h=j1939)
but i'm not sure if it was tested on a 4.9 kernel (seems the branch
comes from 5.0 kernel)
this variant is work in progress for mainline. At this point you still have a chance to
influence the UAPI, adopt your software to it and be able to use latest fixes.
We have the opporunities to change, and our client agree with this,
but i owuld like to be sure to make the correct choice.
>
What is your opinion on this?
Be in sync with mainline is usually best choice at start of project and probably not so
good choice at start of production.
i totally agree with this.
i've started looking more, and what i've seen is that the actual j1939
(from can-next) is based on can version 20170425
and the kernel we plan to use is based on 20120528 (kernel V4.9.
88), so i'm wondering how difficult this can be to use the let's say
"futur mainline"j1939 stack on this kernel.
My experience is that mostly things can be backported with minor effort.
The internal API's tend to change, and some arguments in function
pointer are added, so you need to remove those extras.
maintaining and obsolete version is trivial at first, but will become a
giant task.
OTOH, my/your legacy version contained quite some bugs that have been
identified and solved by now. It's hard to argue that this is today's
best solution.
Except if there is some wor allready done on this base version?
It's not that hard after all, the runtime api haven't really changed,
but the underlying semantics have been made coherent now.
This mostly implies that you have some re-testing to do.
Keeping the legacy j1939 enforces you to stick to your current kernel
version, and some day, that will be a problem, and you will switch
anyway.
Kurt
Kind regards,
Oleksij Rempel
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
