From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4838 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: if_nameindex/getifaddrs and dhcpcd issue Date: Tue, 8 Apr 2014 11:45:37 -0400 Message-ID: <20140408154537.GG26358@brightrain.aerifal.cx> References: <20140408111147.5f79729f@ncopa-desktop.alpinelinux.org> <20140408152559.124030b1@vostro> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1396971957 13995 80.91.229.3 (8 Apr 2014 15:45:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Apr 2014 15:45:57 +0000 (UTC) Cc: justin@specialbusservice.com To: musl@lists.openwall.com Original-X-From: musl-return-4842-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 08 17:45:51 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WXYDe-0006Gy-Md for gllmg-musl@plane.gmane.org; Tue, 08 Apr 2014 17:45:50 +0200 Original-Received: (qmail 13471 invoked by uid 550); 8 Apr 2014 15:45:49 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 13458 invoked from network); 8 Apr 2014 15:45:49 -0000 Content-Disposition: inline In-Reply-To: <20140408152559.124030b1@vostro> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4838 Archived-At: 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