Date: Tue, 8 Apr 2014 11:45:37 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Cc: justin@...cialbusservice.com Subject: Re: if_nameindex/getifaddrs and dhcpcd issue On Tue, Apr 08, 2014 at 03:25:59PM +0300, Timo Teras wrote: > > a lot smaller, but you could make a full netlink library in not much > > more as it is complicated but uniform (I wrote a partly complete one > > in 1000 lines of Lua). > > > > However I can see no reason why dhcp on a specified interface needs to > > enumerate interfaces at all, and it only needs to read ipv4 addresses, > > unless it is implementing dhcp6 too, maybe it does now. Again dhcp6 > > needs netlink, the Musl ipv6 parts for getifaddrs already use /proc > > which is definitely unreliable for early boot config in a distro in my > > view. > > We should not be looking at dhcpd. It's the APIs musl implements: > getifaddrs() and if_nameindex() - they are not currently exposing all > the information they should. One can argue about what if_nameindex should expose; for instance, should it expose all possible interface names the kernel could support, even with modules that haven't been loaded yet? The only thing a strictly conforming application can _DO_ with interface names/numbers is use them for link-local ipv6 scope ids (this is presumably why these functions were added to POSIX in the first place). So, from a conformance standpoint, only exposing ids that could actually appear on a link-local address (i.e. configured interfaces that have ipv6 link-local addresses) would be sufficient. None of this is an argument that it wouldn't be nice to list more interfaces, but it's not a requirement. It's more a matter of providing an additional feature that might be useful to applications. > I'd prefer using netlink, instead of trying to parse and connect data > from various /proc files. > > IMHO, if someone wants to be linux compatible today, it's easier to > implement the netlink stuff; than the /proc stuff. /proc has equally > linux specific things in it and is mainly intended to be human > readable with few exceptions. /sys would be better option as it's > inteded to be machine readable, but it's still text too. /sys is explicitly not usable by libc/apps since policy is that it's not a stable interface. > 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. > 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). Rich
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.