Hi Roy, Roy Marples wrote:
> On 15/01/2021 07:15, matthew green wrote: > >> Oh, I quite agree. However, in6_nbrinfo predates my involvement with NetBSD > >> and is the same struct on all BSD. While bringing the same functionality to > >> IPv4, I elected to keep the same struct just to have the same API, warts > >> and all. I like consistency. Does anyone else have an in_nbrinfo? I _think_ the "asked" member only seems to get assigned a 0 for ipv4, and with a long being 32-bits on any 32 bit platform making it a long instead of an int doesn't buy anything. I'm still keen to make this change (asked as an int instead of a long in in_nbrinfo) and announce a mini flag day for arp for -current users so that it's one less compat32 ioctl we have to maintain. > > [ .. ] > >> > >> That breaks API/ABI though yes? As such it would require stuff in compat > >> anyway, but leaving it as it just needs n32 compat gunk instead which is > >> less impactful on other systems. > > > > in6_nbrinfo/in_nbrinfo are not in any published netbsd release so we can > > choose to break them in -current. there's a slight problem that -current > > has > > a minor flag day here, but it's not the compat issue you seem to think. > > CVS disagrees - in6_nbrinfo is from NetBSD-1, only in_nbrinfo is recent: > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet6/nd6.h?rev=1.14.4.2&content-type=text/x-cvsweb-markup&only_with_tag=netbsd-1-5 Sorry, I only checked the history of in_nbrinfo and just assumed that in6_nbrinfo was of a similar vintage. I've committed compat32 support for SIOCGNBRINFO_IN6 and in6_nbrinfo. Cheers, Simon.