DRAFT 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 :)