Martin Pieuchot is already working in it and it is way more complex than it looked like at the first glance /o\
https://marc.info/?l=openbsd-cvs&m=142546747816025&w=2 > On 14 Mar 2015, at 13:05, Dan Lüdtke <[email protected]> wrote: > > Hi bitrig folks, > > any chance we can get this year old ugliness fixed? How do you feel about it? > > I just wanted to check out the political climate before I start digging into > the code of an OS I never patched before (more a Linux guy). > And politics seems to be an important part of BSD, at least that is my > uneducated impression from the outside. I hope to be wrong. > > Examples of what I'd love to be gone: > > https://github.com/bitrig/bitrig/blob/6221533fdbddb3ca614df5e948d7b0d5a990f635/usr.sbin/bind/lib/isc/unix/interfaceiter.c#L94 > > /* > * BSD variants embed scope zone IDs in the 128bit > * address as a kernel internal form. Unfortunately, > * the embedded IDs are not hidden from applications > * when getting access to them by sysctl or ioctl. > * We convert the internal format to the pure address > * part and the zone ID part. > * Since multicast addresses should not appear here > * and they cannot be distinguished from netmasks, > * we only consider unicast link-local addresses. > */ > if (IN6_IS_ADDR_LINKLOCAL(&sa6->sin6_addr)) { > isc_uint16_t zone16; > > memcpy(&zone16, &sa6->sin6_addr.s6_addr[2], > sizeof(zone16)); > zone16 = ntohs(zone16); > if (zone16 != 0) { > /* the zone ID is embedded */ > isc_netaddr_setzone(dst, > > (isc_uint32_t)zone16); > dst->type.in6.s6_addr[2] = 0; > dst->type.in6.s6_addr[3] = 0; > > > > > https://github.com/bitrig/bitrig/blob/6221533fdbddb3ca614df5e948d7b0d5a990f635/usr.sbin/bgpd/util.c#L71 > /* XXX thanks, KAME, for this ugliness... adopted from route/show.c */ > if (IN6_IS_ADDR_LINKLOCAL(&sa_in6.sin6_addr) || > IN6_IS_ADDR_MC_LINKLOCAL(&sa_in6.sin6_addr)) { > memcpy(&tmp16, &sa_in6.sin6_addr.s6_addr[2], sizeof(tmp16)); > sa_in6.sin6_scope_id = ntohs(tmp16); > sa_in6.sin6_addr.s6_addr[2] = 0; > sa_in6.sin6_addr.s6_addr[3] = 0; > } > > > Is it possible to handle scope_id kernel internally in a struct alongside > with the address? Like some other OS already do in user space? The problem > here is, that this internal handling leaks into user space. Otherwise I > wouldn’t be bothered. > > Any thoughts on that? Should I let it just go? :) > > > Cheers > > > Dan
