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.
