LinuxKPI has no trouble if it is native code for as long as the KPI stays the same I would hope; it'll also have to interface with it from other (driver) parts and LinuxKPI functions.

I assume Linuxolator needs the KBI parts of it?

So it seems we kind-of need it all -- Linuxolator (KBI) or LinuxKPI (KPI) and we also want it native to do the same as Linux and use it for things instead of overloading more routing sockets (and probably DPDK people want it that way too)?

Re KPI: it will change (e.g. support for dynamically adding new commands not here yet) in the short-term, but then should be relatively stable afterwards. The only notion is that the kernel KPI will be different from Linux kernel KPI.

If the KPI, structs, etc. differ from Linux then I fear it's going to be a big name clash for the LinuxKPi bits we need and that means double work and converting everything pointlessly.

That said I see we still have "nla_put", "struct nlattr", .. just with different arguments. I.e. nla_put obviously does not take an skbuff, but why is it called nla_put then as in Linux? It's been a long time but I cannot remember that being part of the RFC? So if we make the KPI differ I kindly ask to make it differ and not just kind-of-the-same-yet-different. I do understand that was work done before your time on this but I hope we can sort those things (even if it is quite a bit of search-replace work) to avoid these conflicts then.

I'm intentionally not looking into Linux kernel bits.

Re name clash: that's very valid concern. There was quite a clash in the routing headers that required some renaming. I don't want to make life harder for the LinuxKPI and happy to change naming to avoid clashes. Kernel part is not a part of RFC, so nothing prevents naming our functions whatever we prefer. struct nlattr is a part of the public user-visible headers so should be the same. I will rename nla_put() to something like nla_append(). Any other potential naming clashes that should be resolved?

Maybe avoid the nla_ prefix for non-public parts to distinguish between RFC and "us". "netl_" or something maybe? I don't know about rtnl*() yet. We have one or of those too.

Ila was a short form of "netlink attribute", so nla_put*() was was a pretty convenient name prefix, as these functions are the most commonly-used part of KPI.
I renamed all these to nlattr_add*(). I also moved all public KPI parts to netlink_ctl.h to simplify things for consumers.

Hope it is better now :-)

Second, would it be better to move the Linux specific code to the Linuxulator? And commit it separately?

I have mixed feelings around it. As far as I understand, we have the code here to (a) colocate all Linux-related business logic there, (b) avoid affecting native code and (c) have it loadable on demand thus not having it in kernel by default.

Speaking of netlink, the there are (1) some linux-specific "core" code which provides in/out hooks allowing transparent message rewrites and (2) actual message convertors, which mostly rewrites families and attributes. The latter resides in netlink_linux.c
I'm fine with moving netlink_linux.c to compat and committing it separately if that's the preference.
Still I'd prefer to have this code present in netlink module by default, as (a) dealing with loading depends and functions pointers would bring more complexity than needed and (b) at this moment I see the amount of code there being relatively small compared to the current (and upcoming) code in the netlink module.

Thoughts?

Looked at that once again. Currently netlink needs 3 functions from linux.ko (and this number will grow when more functionality will be added). On a different side, current rewriting KPI requires 3 functions and this number is unlikely to grow.
Having this code in the Linuxolator looks like a right target to me, though I'm vague on the implementation.
Core module can certainly have some hooks/pointers defined/exported & provide stubs to switch to if Linuxolator is not loaded.
However, I'm not sure on the mechanism that would do this switch back and forth, provided both linux and netlink modules can be loaded independently.