Re: FreeBSD-native CAN Stack and AF_CAN Protocol Family

On Fri, Jun 20, 2025 at 6:52 AM Jérémie JOURDIN
<jeremie.jourdin@advens.fr> wrote:
>
> Hello all,
>
>
>
> I am working on a system (15-current) that requires interaction with a CAN network.
>
> So far, I have developped a driver for my controller, able to send and receive CAN frames to and from connected devices.
>
>
>
> I’d like to implement a FreeBSD-native CAN network stack that is API-compatible with Linux’s Netlink CAN (netcan).
>
> This would allow us to recompile and use existing Linux userland tools with minimal changes.
>
>
>
> If you believe this development could benefit the community, I would be happy to submit a set of patches (driver + netcan support).
>
>
>
> We’re considering defining a new Protocol Family, AF_CAN, for this purpose.
>
> Would it be acceptable to use the first available « AF_VENDORXX » from sys/socket.h ?

I think there's a nuance here. Even AF_xxx values are in the base
system, while odd values are for vendors.

If you don't care about the final value, and accept it will change,
you can use #define AF_CAN AF_VENDOR00 until we're closer to
committing to the tree, and change it to something like 48 or 50.
That's what I'd recommend: it breaks ABI compat for you, which for
most people won't be a problem.

If it is a problem, the best we can do is to move up when we, the
FreeBSD project, allocate the value. But let's hope we can defer that
until the software has been written and is entering a public test and
review phase. That help the project balance between just handing them
out, leading to table with lots of blank entries that can never be
reclaimed which can be hard on cache lines, vs waiting too long and
having people need to have the odd value, or risking a collision with
changes super late in deployment.

As for CAN, I love the idea. I started porting the Linux CANBUS code
since it was, years ago, dual licensed. But I'm now 20 years beyond
that, give or take, and have no gear or need for it...

Warner

>
>
>
> I would appreciate your thoughts, advice, and any recommendations you may have on this matter.
>
>
>
> -- Jérémie