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
