From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4858 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: Wed, 9 Apr 2014 18:18:43 -0400 Message-ID: <20140409221843.GJ26358@brightrain.aerifal.cx> References: <20140408111147.5f79729f@ncopa-desktop.alpinelinux.org> <20140408134255.GE26358@brightrain.aerifal.cx> <20140408153840.GF26358@brightrain.aerifal.cx> <20140409091348.3159011a@ncopa-desktop.alpinelinux.org> 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 1397081946 11370 80.91.229.3 (9 Apr 2014 22:19:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Apr 2014 22:19:06 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4862-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 10 00:18:58 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 1WY0pd-0008Sm-UA for gllmg-musl@plane.gmane.org; Thu, 10 Apr 2014 00:18:58 +0200 Original-Received: (qmail 11266 invoked by uid 550); 9 Apr 2014 22:18:56 -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 10234 invoked from network); 9 Apr 2014 22:18:56 -0000 Content-Disposition: inline In-Reply-To: <20140409091348.3159011a@ncopa-desktop.alpinelinux.org> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4858 Archived-At: On Wed, Apr 09, 2014 at 09:13:48AM +0200, Natanael Copa wrote: > On Tue, 8 Apr 2014 11:38:41 -0400 > Rich Felker wrote: > > > On Tue, Apr 08, 2014 at 03:16:10PM +0100, Justin Cormack wrote: > > > I was under the impression that the ioctl-based interface for ipv6 is > > > incomplete under Linux. > > > > Probably "incomplete" in a sense that it can't do some special-purpose > > stuff that most users don't need. > > You cannot get the configured ipv6 addresses via SIOCGIFCONF. That is > why musl needs to parse /proc for that. > > ioctl-based interface for ipv4 is also "incomplete". You cannot get > anything else than the primary address so current musl getifaddrs will > not give you all configured ipv4 addresses. > > > Busybox entirely avoids netlink, as > > far as I can tell, > > Not entirely. the iproute implementation in bb uses netlink, but you > can of course disable that during configuration. A quick grep also > indicate that busybox ifplugd uses netlink. > > > and it's perfectly acceptable for setting up ipv6, > > at least in simple setups. You don't even need busybox's iproute2 > > workalikes; ifconfig and route work fine. > > And if you do that, then you cannot assign more than one ip addr on > each interface. (you'll have to use alias, eth0:1 for that), but yes, > thats no longer a simple setup. OK, based on what you're saying, the ioctl interface is unable to report the existence of interfaces that have only an ipv6 address configured but no ipv4 addresses. If that's true, then yes, it's unusable and we need a different approach, either /proc or netlink. I'm happy to look at both approaches and see which is more efficient. One advantage of netlink is that it can work before /proc is mounted. However, it's documented that a fair number of interfaces in libc depend on /proc, so unless you're going to audit programs for which libc functions they use, it really makes sense to just make sure /proc is mounted first. There's really no good reason for mounting /proc not to be the first line of the init scripts. It also might be able to make the netlink-based code smaller (in terms of what gets static linked) than a proc-based version, since stdio/scanf is costly. One advantage of /proc is that, on a non-linux system, you can just drop static file in place with contents matching your machine's configuration. Rich