[PATCH] IPv4 over IPv6 nexthop support on FreeBSD

[Ondrej Zajicek]

On Mon, Jun 19, 2023 at 10:32:45AM +0100, Alexander Chernikov wrote:
> > There is a question how handle feature divergence (primarily divergence
> > in which structures and enum values are defined for compile-time) in
> > Netlink between Linux and FreeBSD. I would prefer to not have autoconf
> > test for each such feature. For example we could probably remove
> > HAVE_MPLS_KERNEL altogether just for Linux (as the check is unnecessary
> > for non-obsolete kernels, but i am not sure about FreeBSD headers).
>
> I understand the pain. To add to this, the feature existence doesn’t always mean the full feature parity.
> For example, current nexthop/nexthop group implementation doesn’t have the support for adding resilient nexthop groups.
> 
> The only solution I could think of is adding a bit of ugliness to the headers and have the defines for each enum item (for commands) and a separate define for the structures / small enums.
> Then the features could be defined in the sysdep/<flavor>/netlink-sys.h .
> 
> What do you think?

I think it would be nice.

First, i thought it does not really help considering they are not in
Linux kernel headers and even when added, we would still need to support
older ones, but we can just define them for Linux in sysdep/linux/netlink-sys.h

Strange is that some enums in Linux rtnetlink headers have these
(e.g. RTM_* values), while others do not * (e.g. RTN_* values):

enum {
        RTM_BASE        = 16,
#define RTM_BASE        RTM_BASE

        RTM_NEWLINK     = 16,
#define RTM_NEWLINK     RTM_NEWLINK
        RTM_DELLINK,
#define RTM_DELLINK     RTM_DELLINK
        RTM_GETLINK,
#define RTM_GETLINK     RTM_GETLINK
        RTM_SETLINK,
#define RTM_SETLINK     RTM_SETLINK
...

enum {
        RTN_UNSPEC,
        RTN_UNICAST,            /* Gateway or direct route      */
        RTN_LOCAL,              /* Accept locally               */
        RTN_BROADCAST,          /* Accept locally as broadcast,
                                   send as broadcast */
...

(not sure if there is any system in that, or just usual ad-hoc
inconsistencies)

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."