Date: Tue, 8 Apr 2014 19:08:07 +0300 From: Timo Teras <timo.teras@....fi> To: musl@...ts.openwall.com Cc: dalias@...ifal.cx, justin@...cialbusservice.com Subject: Re: if_nameindex/getifaddrs and dhcpcd issue On Tue, 8 Apr 2014 11:45:37 -0400 Rich Felker <dalias@...ifal.cx> wrote: > > netlink is here to stay, there's no alternate way to do certain > > things. So I'd rather use it. It's the interface kernel people > > intended to be used for the thing in question. > > As I mentioned on IRC, the current netlink protocol is deficient; my > understanding is that it's incapable of representing hardware > addresses longer than a certain fixed length, leading to truncation of > infiniband addresses. I'm not an expert on this but I seem to remember > someone (IIRC Rob Landley) knows the details. I'm not sure how fixable > this is, but it's not a problem at all with a clean text-based > interface like /proc provides. Netlink is very extensible. If this is the case they have messed up some struct that exposes. glibc has some struct sockaddr_ll_max hack. It is not due to netlink. It's due to getifaddrs() interface exposing struct sockaddr* and it's using AF_PACKET that maps to struct sockaddr_ll. struct sockaddr_ll cannot hold infiniband address, but glibc is 'overriding' the struct to hold it anyway. Basically it's getifaddrs() API that is botched, But as to netlink, all the addresses I've looked at are not wrapped in struct sockaddr. They are netlink 'attributes' that are variable length. The only ABI mess in netlink has been with 32-bit apps running on 64-bit kernels. And it has been kernel header issue. Please let me know details on the claimed deficiency of netlink. It *a lot* better (but also a bit complicated - and even more often misunderstood [because the #define's exposed by kernel to use it is garbage]) than the the traditional APIs IMHO. The 'on wire' protocol of netlink is usable though. > > I'm willing to write an alternative getifaddrs() and if_nameindex() > > implementations using netlink. Perhaps let's see how they end up? > > It wouldn't hurt; if they're not upstreamed they could still be used > as a separate library for the one application which needs this > functionality (dhcpcd). Yeah. I'll play with this and see what I come up with. I'll also delete the bad kernel #define's and try to do them a bit better - not sure how well I succeed that at, though.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.