Changeset View
Standalone View
sys/modules/netlink/Makefile
- This file was added.
.PATH: ${SRCTOP}/sys/netlink | |||||
KMOD= netlink | |||||
SRCS = netlink_module.c netlink_domain.c netlink_iface.c netlink_io.c \ | |||||
netlink_message.c netlink_route.c netlink_nhop.c netlink_linux.c | |||||
dchagin: first of all, thanks for doing this, NL is a much needed piece of linux in the Linuxulator… | |||||
Done Inline ActionsLinuxKPI 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)? bz: LinuxKPI has no trouble if it is native code for as long as the KPI stays the same I would hope… | |||||
Done Inline ActionsRe 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. melifaro: Re KPI: it will change (e.g. support for dynamically adding new commands not here yet) in the… | |||||
Done Inline ActionsIf 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. bz: If the KPI, structs, etc. differ from Linux then I fear it's going to be a big name clash for… | |||||
Done Inline ActionsI'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? melifaro: I'm intentionally not looking into Linux kernel bits.
Re name clash: that's very valid concern. | |||||
Done Inline ActionsMaybe 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. bz: Maybe avoid the nla_ prefix for non-public parts to distinguish between RFC and "us". "netl_"… | |||||
Done Inline ActionsIla 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. Hope it is better now :-) melifaro: `Ila` was a short form of "netlink attribute", so `nla_put*()` was was a pretty convenient name… | |||||
Done Inline Actions
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 Thoughts? melifaro: > Second, would it be better to move the Linux specific code to the Linuxulator? And commit it… | |||||
Done Inline ActionsLooked 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. melifaro: Looked at that once again. Currently netlink needs 3 functions from linux.ko (and this number… | |||||
.include <bsd.kmod.mk> |
first of all, thanks for doing this, NL is a much needed piece of linux in the Linuxulator since glibc moved some of if_XXX code to NL.
Second, would it be better to move the Linux specific code to the Linuxulator? And commit it separately?