Hi Dan, First of all, sorry for replying only now and thanks for getting in touch!
This really looks ugly and I’m glad to see OpenBSD/mpi@ tackle it already. I’m sure they’ll properly take care of it. That said, if you’re interested in working on anything, just let us know. We’re open for change. We’re also usually available on IRC, where you can chat with us about things directly. Good night, Patrick > Am 14.03.2015 um 15:05 schrieb Dan Lüdtke <[email protected]>: > > 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 > >
