netdev - Re: Kernel header changes break glibc build

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 4 Dec 2006 10:13:41 +0100
From:	Thomas Graf <tgraf@...g.ch>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	"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

* David Woodhouse <dwmw2@...radead.org> 2006-12-03 12:25
> Thomas, this is in response to your changes in
> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1823730fbc89fadde72a7bb3b7bdf03cc7b8835c;hp=47f68512d2685431f1781830dfcbab31bda87644
> in which you create <linux/if_addr.h> and require that it's included
> directly rather than being part of (or even included from)
> <linux/rtnetlink.h>. Was there a good reason for changing that
> user-visible header? Is there a reason not to include if_addr.h from
> rtnetlink.h as Joseph's patch does?

Userspace is not supposd to directly include kernel headers, instead
it has to make local copies and compile against them. Binary
compatibility is always guaranteed but in times of development within
a stable tree it's wrong to assume that headers never change.

I do not agree with the change to include if_addr.h in rtnetlink.h.
The point is to move bits apart and have multiple small pieces
of header files defining a specific rtnetlink family which are a
lot easier to maintain for both kernel and userspace than one giant
rtnetlink.h for everything.

> I suspect that if the IF{L,}A_{PAYLOAD,RTA} macros aren't used in the
> kernel then the best answer is for glibc to define those for itself.

Right, if they did it right they would only have noticed when they
updated the kernel headers to some newer versions and only had to
move the bits to some compat header.
-
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