[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140408154537.GG26358@brightrain.aerifal.cx>
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.
