[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061206213556.GH8693@postel.suug.ch>
Date: Wed, 6 Dec 2006 22:35:56 +0100
From: Thomas Graf <tgraf@...g.ch>
To: Al Viro <viro@....linux.org.uk>
Cc: Jakub Jelinek <jakub@...hat.com>,
David Woodhouse <dwmw2@...radead.org>,
Ulrich Drepper <drepper@...hat.com>,
"Joseph S. Myers" <joseph@...esourcery.com>,
netdev@...r.kernel.org, libc-alpha@...rceware.org, akpm@...l.org,
"David S. Miller" <davem@...emloft.net>
Subject: Re: Kernel header changes break glibc build
* Al Viro <viro@....linux.org.uk> 2006-12-06 20:34
> On Wed, Dec 06, 2006 at 09:26:39PM +0100, Thomas Graf wrote:
> > * Al Viro <viro@....linux.org.uk> 2006-12-06 17:13
> > > On Wed, Dec 06, 2006 at 03:31:46PM +0100, Thomas Graf wrote:
> > >
> > > > At the time they were added they were meant to be exported but netlink
> > > > has evolved and we now have a type safe API.
> > >
> > > Where? AFAICS, netlink might be considered type-safe only within an
> > > address family...
> >
> > The new interface can be found in net/netlink.h, it obsoletes the
> > old interface which is spread over linux/netlink.h and linux/rtnetlink.h
>
> ... and for different address families you have conflicting policies.
> You can't tell if ATTR_... means __le16, __be32, 16byte-array or something
> else - the answer depends on the code interpreting the damn thing.
> Moreover, you get zero warnings if you use wrong accessor to decode.
That's right, some attribute cary address specific content such
as addresses. By type safe I meant the API which no longer consists
of macros prone to errors. I didn't mean to say netlink attributes
are now type safe.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists