From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4839 Path: news.gmane.org!not-for-mail From: Timo Teras Newsgroups: gmane.linux.lib.musl.general Subject: Re: if_nameindex/getifaddrs and dhcpcd issue Date: Tue, 8 Apr 2014 19:08:07 +0300 Message-ID: <20140408190807.7dc6b184@vostro> References: <20140408111147.5f79729f@ncopa-desktop.alpinelinux.org> <20140408152559.124030b1@vostro> <20140408154537.GG26358@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1396973214 2788 80.91.229.3 (8 Apr 2014 16:06:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Apr 2014 16:06:54 +0000 (UTC) Cc: dalias@aerifal.cx, justin@specialbusservice.com To: musl@lists.openwall.com Original-X-From: musl-return-4843-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 08 18:06:47 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 1WXYXv-0003Qb-8y for gllmg-musl@plane.gmane.org; Tue, 08 Apr 2014 18:06:47 +0200 Original-Received: (qmail 24142 invoked by uid 550); 8 Apr 2014 16:06:46 -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 24131 invoked from network); 8 Apr 2014 16:06:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=+yosfC/1/JKu+CbBeESN06uW/syiOIcaUHyTf8FPX44=; b=sGx0H9rKTTN/EJSQWd8zH8U5+f9R2geqQvloViSvCqumI4dKvw+1SmrG2JZnZI/DRs IGMnup/UUbJW9HjKCM9yMjFffPfYmOoJrw8/nOdHx1unUjSnEAPIdCwnHb+G1fa4OCnf FvBafV7Ke+h+WLPP9+O9gnXjZHoXMBUn9x5/v/z5/ArA5CkLxPx5ziz1MO2qtPxSkpyT qdBpR6GQEAaLS7HzZ0p0xdoPnfcIT2vH+dSHlBnT+9agHbv2koSbkxx7/IHfIXKSJTg9 f9fQcJN3lQE5b8gYQNRtc+vxi/cVoY+mY8VDmpxZcxQjZV1tWRPagiL/AiXlCEphtP77 anYw== X-Received: by 10.152.42.144 with SMTP id o16mr3500340lal.9.1396973194881; Tue, 08 Apr 2014 09:06:34 -0700 (PDT) Original-Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= In-Reply-To: <20140408154537.GG26358@brightrain.aerifal.cx> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; i486-alpine-linux-uclibc) Xref: news.gmane.org gmane.linux.lib.musl.general:4839 Archived-At: On Tue, 8 Apr 2014 11:45:37 -0400 Rich Felker 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.