[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140408190807.7dc6b184@vostro>
Date: Tue, 8 Apr 2014 19:08:07 +0300
From: Timo Teras <timo.teras@....fi>
To: musl@...ts.openwall.com
Cc: dalias@...ifal.cx, justin@...cialbusservice.com
Subject: Re: if_nameindex/getifaddrs and dhcpcd issue
On Tue, 8 Apr 2014 11:45:37 -0400
Rich Felker <dalias@...ifal.cx> 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.
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.
