Thanks all for your answer. I will see with project team what is the best for us regarding delay/planning/cost as this is what will makje the decision. Kurt i just quick integrate your versiob, and it works fine (at least for nominal use case, i did not have time to go further). Best regards Laurent On Thu, Apr 25, 2019 at 11:50 AM Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx> wrote: > > 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 |
