Leverage the kernel J1939 implementation for socketcan interfaces?

[robynnepiers]

According to the What's New for the socket library, Python 3.9+ supports the kernel J1939 protocol family on supported Linux kernel versions. This is kernel 5.4+ per the eLinux wiki, which is the version shipped with Ubuntu 20.04 LTS.

I'm not sure how feasible this is considering the API this library provides and the desire to support Python 2 (although I suppose this could just be treated as progressive enhancement or an option that can be opted into, falling back to the userspace implementation if unavailable), but it would be nice to support an abstraction of that as well so the work can be deferred to the kernel instead of the implementation being purely userspace in Python.

[milhead2]

That sounds like a great idea!
It will be a while before we can divorce python<3.9 or kernel<5.4 but I like the idea of automatically picking up the kernel support for J1939 if it's available.. It would probably expose a rash of errors in this code to get a kernel implementation to talk to a python one but it does drive long-term support down and eventually to near-0.
I do a lot of socketcan work during the day and have seen mention of the J1939 features but not tried to use them. We've supported our own stacks for so long on our embedded projects we have no immediate plans to change.
For this library however; The direction you are taking sounds exciting, mostly because I generally run all of our test environment which this library contributes to on Linux. At times execution speed has been an issue, especially when we install everything on a $50 Beagleboard. A kernel implementation would help mitigate that.
My time is quite limited and I try mostly to keep up with the odd bug report, is there any chance you would be interested to give it a whirl? Let me know, I'm always eager to get others involved in the library.
Mil

[polybassa]

Hi, I followed your discussion. In the past I did a similar thing for isotp sockets. There is a kernel module available, which I could use for python 3. On python 2 I had to wrap the functionality in Userland. Maybe my python 3 code can be useful for what you want to do. You can find everything here: https://github.com/secdev/scapy/blob/master/scapy/contrib/isotp.py The relevant class is called ISOTPNativeSocket. Maybe this safes you some time. Cheers Nils

…

On August 20, 2020 5:26:45 PM GMT+02:00, Miller Lowe ***@***.***> wrote: That sounds like a great idea! It will be a while before we can divorce python<3.9 or kernel<5.4 but I like the idea of automatically picking up the kernel support for J1939 if it's available.. It would probably expose a rash of errors in this code to get a kernel implementation to talk to a python one but it does drive long-term down and eventually 0. I do a lot of socketcan work during the day and have seen mention of the J1939 features but not tried to use them. We've supported our own stacks for so long on our embedded projects we have no immediate plans to change. For this library however; The direction you are taking sounds exciting, mostly because I generally run all of our test environment which this library contributes to on Linux. My time is quite limited and I try mostly to keep up with the odd bug report, is there any chance you would be interested to give it a whirl? Let me know, I'm always eager to get others involved in the library. Mil -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #12 (comment)