Ready2Review Kernel mod wrapper acf-can - Do not merge

[SebastianSchildt]

Not ready to merge. But we need to talk....

This extends the acfcan examples with one that wraps the functionality into virtual can interfaces in Linux, much like vcan does.

It still is reusing the main Open1722 code (not as a "lib" obviously). The issue is, that certain standard C headers are not available in kernel space, instead replacements are offered (e.g. for <string.h> or <errno.h> .

In this PR currently I sort of suggest two ways to deal with this. Both are based on having a define
LINUX_KERNEL1722 that is only set when building the module.

This can then either be used directly wherever needed, see e.g. https://github.com/boschglobal/Open1722/blob/7c7e6dcb5bae5a1cc3671deabaf187950f6338c0/src/avtp/Utils.c#L30-L34

or as I did for the stdint case, split in a seperate file like here https://github.com/boschglobal/Open1722/blob/fun/acfcan-kernelmod-wrapper/include/avtp/IntTypes.h and see usage here
https://github.com/boschglobal/Open1722/blob/7c7e6dcb5bae5a1cc3671deabaf187950f6338c0/include/avtp/acf/Can.h#L39

Generally to make sure it not "breaks" as I guess most development is done on the user space lib, whe should probably add a GH action that would build the module. Might need some live-sed patching during build due to the license issue mentioned in the Readme

[SebastianSchildt]

Ah I should also have said somehting about the 1722 aspects of this :D So well if you are lucky it sends a "sort-of" good acf-can frame when you send a non-fd packet on the vritual can. So some legwork still to do, Currently more like a scaffolding showing how to integrate the existing 1722 code into the kernel mod example... No receive path yet

[nayakned]

I could get the path from CAN->Ethernet running on my setup. However, I had to go through the hassle of signing the kernel module. Somehow my VM did not accept unsigned kernel module despite all the settings.

[SebastianSchildt]

Ethernet to CAN impl still pending. I developed on ubuntu 24 on x64 and arm64. Signing never came up as an issue that environment (wasn’t even aware kernel mods actally CAN be signed :)

[SebastianSchildt]

This is ready to test @nayakned @adriaan-niess

I think it is "feature-complete" as an initial working version.

There is a Readme, see rendered version here https://github.com/boschglobal/Open1722/blob/fun/acfcan-kernelmod-wrapper/examples/acf-can/linux-kernel-mod/Readme.md

Even in the unlikely case this is working perfectly for you and you give a thumbs up, pls do not merge it yet. This needs some serious squashing of commits.

[nayakned]

Looks awesome. Tested with cangen -m ecu1& cangen -m ecu2&. Compared the outputs then on candump ecu1 and candump ecu2
I had trouble though to get it working only following the Readme alone though.
Two issues: One I needed to execute modprobe can as Ubuntu didnt load CAN modules for me. Secondly, I am not able to load unsigned kernel modules on my Ubuntu VM. But perhaps thats my problem alone due to secure boot. We should perhaps add links (e.g., https://ubuntu.com/blog/how-to-sign-things-for-secure-boot) to information on how to generate keys, load private keys and sign kernel modules in the Readme.