On Mon, May 30, 2022 at 12:07:01PM +0100, Stuart Henderson wrote: > On 2022/05/29 14:20, Andrew Cagney wrote: > > On Sun, 29 May 2022 at 13:44, Stuart Henderson <s...@spacehopper.org> wrote: > > > > > > On 2022/05/29 19:08, Florian Obser wrote: > > > > On 2022-05-29 12:27 -04, Andrew Cagney <andrew.cag...@gmail.com> wrote: > > > > > > Are you porting libreswan? > > > > Slowly. > > Good luck - it would be nice to have this running. I'm happy to help > get it into ports in future. > > > > This configure flag literally just installs the header file, that's all. > > > If there's a good reason for it, we could do that. > > > > Performance. It lets libunbound use a common (crypto heavy) thread pool. > > I've added this to ports/net/libunbound, it will show up in future > package builds. > > > > For (RT_)ADVANCE, we try to avoid header pollution. Suggest you just > > > make a local copy of the definition as is done in route.c. > > > > That's why I'm suggesting adding RT_ADVANCE(). The name, which I'm > > lifting from NetBSD, at least includes RT_*(), unlike FreeBSD's > > SA_SIZE(). I'd prefer to be relying on something that's part of a > > published interface, rather than magically gleaned from source code. > > Hmm, yes, it doesn't seem to be documented in the OS at all (at least > nothing returned by "man -k any=sa_len" describes how to advance past > padding), which is not ideal. Whether a common macro is needed or > not I can't really say (though it _would_ be helpful to have if we > were ever to change the alignment from long to 64-bit). > > I looked at other software using RT_ROUNDUP/RT_ADVANCE in Debian > codesearch; in terms of whether adding them would cause any actual > problems in ports, things would be good on that front. As far as > ports is concerned there is no barrier to adding this. > > openvpn: uses RT_ROUNDUP on NetBSD, has its own definitions handling > Darwin (pads to 32 bits), FreeBSD/OpenBSD (pads to long). useful commentary > at https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/route.c#L3400= > > dhcpcd: uses RT_ADVANCE if present, otherwise has its own definition > (pads to long on BSD, 32 bit on Solaris) > > openvswitch: uses RT_ADVANCE but only has code handling these features > on NetBSD anyway > > vendored libdnet in nmap: uses RT_ROUNDUP on NetBSD, otherwise 32 bit > on Darwin otherwise long. > > net-snmp, frr/zebra: uses SA_SIZE/RT_ROUNDUP if present, otherwise long. > > there is something in pcp as well, but appears to be NetBSD-only code.
In general I'm all for having a few convinience macros to properly build routing messages. The padding is indeed a but of pain point. I think I prefer RT_ROUNDUP over SA_SIZE from a naming perspective. What needs to be done is to make sure net/route.h is not included by other userland headers. Only pfvar.h seems to pull in net/route.h (I guess for the pf table bits). So adding new objects to the namespace in net/route.h should have a limited affect. From my understanding net/route.h is only needed as an include for the routing socket. Since the routing socket code is heavily OS dependent (even the BSD diverged enough from each other to make it impossible to simply reuse the same code) I see little problems with adding RT_ROUNDUP (or what ever we want to call it). Doing this should be done by looking at the various kroute.c and other routing socket / route sysctl users and decide what kind of macros will help making the code cleaner. I'm happy to review diffs for this but have no time to pull this myself. -- :wq Claudio
