Canbus support in the kernel for C program

I am trying to port a 3D printer firmware / daemon called Klipper to run on FreeBSD. So far it all went well until it wanted to <linux/can.h>

I am running out of places to look for that file. I don't see it anywhere in the standard libraries. Is there canbus support in FreeBSD? If so, where can I locate the header file?
 
or would it require some work to port over?
I am not a programmer by trade so I cannot answer that.
What I can say is that several FreeBSD drivers have NetBSD origins, just like OpenBSD.

That said it is probably a better code learning guide than any Linux. It will not be a direct swap in.
Especially seeing how CAN has 3 distinct areas of concern:

-canctl
-can network hooks
-canbus protocol

I could see NetBSD having a slightly different ifconfig code base that may need adjusting to FreeBSD.

CAN would have been a great addition to my FreeBSD Foundation Wish List.

That FreeBSD is not in use in vehicle computer systems is disappointing.

Which brings me to this question:
How could a 3D printer firmware need CAN ?
Needing just a header file is one thing, but a printer needing CAN is preposterous.
 
I am not a programmer by trade so I cannot answer that.
What I can say is that several FreeBSD drivers have NetBSD origins, just like OpenBSD.

That said it is probably a better code learning guide than any Linux. It will not be a direct swap in.
Especially seeing how CAN has 3 distinct areas of concern:

-canctl
-can network hooks
-canbus protocol

I could see NetBSD having a slightly different ifconfig code base that may need adjusting to FreeBSD.

CAN would have been a great addition to my FreeBSD Foundation Wish List.

That FreeBSD is not in use in vehicle computer systems is disappointing.

Which brings me to this question:
How could a 3D printer firmware need CAN ?
Needing just a header file is one thing, but a printer needing CAN is preposterous.
Klipper uses CANbus for some very high end printers. Most of the time it doesn't use CANbus, sadly for my needs its more of a build dependency rather than a needed feature.
 
Then I would use the NetBSD source codebase for your can.h needs if it works.
Compilers are quite vocal so you should be able to pinpoint any additional needed dependencies.
The NetBSD source tree may have a different organization as well. So it may take some studying for file placement.
I would only copy over the bare minimum and use compiler errors for further actions.
This seems to be the top level directory for can.h
 
The problem I see is inevitably you need more than a header file (can.h).
The real meat and potatoes are the 'c' functions. So you need to see what Klipper needs from can.h and trace it.
NetBSD can.h might not even contain what you need. You may need the Linux version.

Just look at all the other dependencies of NetBSD can.c. Quite a rabbithole.
What are the chances FreeBSD has all these and they work the same? That is what you need to checkout.
#include <sys/param.h>
#include <sys/systm.h>
#include <sys/mbuf.h>
#include <sys/ioctl.h>
#include <sys/domain.h>
#include <sys/protosw.h>
#include <sys/errno.h>
#include <sys/socket.h>
#include <sys/socketvar.h>
#include <sys/proc.h>
#include <sys/kauth.h>

#include <net/if.h>
#include <net/if_types.h>
#include <net/netisr.h>
#include <net/route.h>
#include <net/bpf.h>

#include <netcan/can.h>
#include <netcan/can_pcb.h>
#include <netcan/can_var.h>
 
The NetBSD source tree may have a different organization as well. So it may take some studying for file placement.
For example I see that on NetNSD this resides in /sys/netcan/ but on FreeBSD this would reside in /sys/dev/netcan/

When the source tree is referenced it is common to leave off the full directory path and exclude /usr/src/.
This is because you need to change directory to /usr/src/ to compile base system.
To compile individual components of base you must change directory to the component you want to compile.
 
So can you remove or make optional that dependency?

Sprinkle a few ifdefs?

Might not be feasible but might be less work (at least initially while you see if any other issues.)
I can't remove it without making problems. Klipper is part C and part Python. Also its a project that is a bit WIP. I had though about doing that very thing. Perhaps I should revisit that idea.
 
Back
Top