[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140409221843.GJ26358@brightrain.aerifal.cx>
Date: Wed, 9 Apr 2014 18:18:43 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: if_nameindex/getifaddrs and dhcpcd issue
On Wed, Apr 09, 2014 at 09:13:48AM +0200, Natanael Copa wrote:
> On Tue, 8 Apr 2014 11:38:41 -0400
> Rich Felker <dalias@...ifal.cx> 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
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.
