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? 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
