Kernel header changes break glibc build

classic Classic list List threaded Threaded
53 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Kernel header changes break glibc build

Joseph Myers
The kernel headers installed by Linux 2.6.19-rc1 "make
headers_install" do not work for building glibc, because glibc expects
<linux/rtnetlink.h> to provide various definitions, some of which have
been moved to <linux/if_addr.h> and some of which have been removed
altogether.

This kernel patch allows glibc to build again by making rtnetlink.h
include if_addr.h and adding back the removed definitions required by
glibc, but I don't know if it's the correct approach or if glibc
should change the headers it includes and add its own macro
definitions.

Signed-off-by: Joseph Myers <[hidden email]>
---
Index: include/linux/rtnetlink.h
===================================================================
--- include/linux/rtnetlink.h
+++ include/linux/rtnetlink.h
@@ -2,6 +2,7 @@
 #define __LINUX_RTNETLINK_H
 
 #include <linux/netlink.h>
+#include <linux/if_addr.h>
 #include <linux/if_link.h>
 
 /****
Index: include/linux/if_link.h
===================================================================
--- include/linux/if_link.h
+++ include/linux/if_link.h
@@ -82,6 +82,9 @@
 
 #define IFLA_MAX (__IFLA_MAX - 1)
 
+#define IFLA_RTA(r)  ((struct rtattr*)(((char*)(r)) + NLMSG_ALIGN(sizeof(struct ifinfomsg))))
+#define IFLA_PAYLOAD(n) NLMSG_PAYLOAD(n,sizeof(struct ifinfomsg))
+
 /* ifi_flags.
 
    IFF_* flags.
Index: include/linux/if_addr.h
===================================================================
--- include/linux/if_addr.h
+++ include/linux/if_addr.h
@@ -52,4 +52,7 @@
  __u32 tstamp; /* updated timestamp, hundredths of seconds */
 };
 
+#define IFA_RTA(r)  ((struct rtattr*)(((char*)(r)) + NLMSG_ALIGN(sizeof(struct ifaddrmsg))))
+#define IFA_PAYLOAD(n) NLMSG_PAYLOAD(n,sizeof(struct ifaddrmsg))
+
 #endif



--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Kernel header changes break glibc build

David Woodhouse-7
On Fri, 2006-10-06 at 17:20 +0000, Joseph S. Myers wrote:

> The kernel headers installed by Linux 2.6.19-rc1 "make
> headers_install" do not work for building glibc, because glibc expects
> <linux/rtnetlink.h> to provide various definitions, some of which have
> been moved to <linux/if_addr.h> and some of which have been removed
> altogether.
>
> This kernel patch allows glibc to build again by making rtnetlink.h
> include if_addr.h and adding back the removed definitions required by
> glibc, but I don't know if it's the correct approach or if glibc
> should change the headers it includes and add its own macro
> definitions.
>
> Signed-off-by: Joseph Myers <[hidden email]>

Since it was Thomas Graf who made these changes and David Miller who
committed them, you'd do well to Cc both of those people.

Sorry for the delayed response on my part -- I've been away
concentrating on OLPC stuff, and just about everything else has fallen
by the wayside.

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?

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.

> ---
> Index: include/linux/rtnetlink.h
> ===================================================================
> --- include/linux/rtnetlink.h
> +++ include/linux/rtnetlink.h
> @@ -2,6 +2,7 @@
>  #define __LINUX_RTNETLINK_H
>  
>  #include <linux/netlink.h>
> +#include <linux/if_addr.h>
>  #include <linux/if_link.h>
>  
>  /****
> Index: include/linux/if_link.h
> ===================================================================
> --- include/linux/if_link.h
> +++ include/linux/if_link.h
> @@ -82,6 +82,9 @@
>  
>  #define IFLA_MAX (__IFLA_MAX - 1)
>  
> +#define IFLA_RTA(r)  ((struct rtattr*)(((char*)(r)) + NLMSG_ALIGN(sizeof(struct ifinfomsg))))
> +#define IFLA_PAYLOAD(n) NLMSG_PAYLOAD(n,sizeof(struct ifinfomsg))
> +
>  /* ifi_flags.
>  
>     IFF_* flags.
> Index: include/linux/if_addr.h
> ===================================================================
> --- include/linux/if_addr.h
> +++ include/linux/if_addr.h
> @@ -52,4 +52,7 @@
>   __u32 tstamp; /* updated timestamp, hundredths of seconds */
>  };
>  
> +#define IFA_RTA(r)  ((struct rtattr*)(((char*)(r)) + NLMSG_ALIGN(sizeof(struct ifaddrmsg))))
> +#define IFA_PAYLOAD(n) NLMSG_PAYLOAD(n,sizeof(struct ifaddrmsg))
> +
>  #endif
>
>
>
--
dwmw2

Reply | Threaded
Open this post in threaded view
|

Re: Kernel header changes break glibc build

Thomas Graf
* David Woodhouse <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Kernel header changes break glibc build

David Woodhouse-7
On Mon, 2006-12-04 at 10:13 +0100, Thomas Graf wrote:
> Userspace is not supposd to directly include kernel headers, instead
> it has to make local copies and compile against them.

No. It was _never_ sensible to simply declare that userspace "shall not
use kernel headers" in the absence of any serious alternative. It was
always just a cop-out.

Historically, there were a number of efforts to provide 'sanitised'
kernel headers which are needed for userspace to build against. Various
people forked headers from the kernel at different times, got burned out
at different times, took different approaches w.r.t. how much abuse of
kernel-private stuff should be permitted. We ended up with a bunch of
inconsistent sets of 'kernel headers' each done differently and updated
sporadically.

Thankfully, this is no longer the case. The kernel now has a
'headers_install' make target which spits out those headers which are
suitable for userspace, sanitised by removing anything within
__KERNEL__. We have a _consistent_, up to date set of headers which
distributions can use for building glibc and other system libraries and
tools. Some distributions are already shipping like that; others are
still working on doing so.

> 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.

That makes some sense, but we need to be more careful about making
incompatible changes in the headers which we export -- it's no longer
acceptable to just toss a pile of crap over the wall and declare it to
be someone else's problem.

That isn't to say that we should _never_ make such changes, but we
should at least make sure we think about it and make sure that glibc
adapts to cope, _before_ people start to see build failures.

> > 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.

No. They _are_ doing it right -- they're running 'make headers_install'
against the 2.6.19 kernel and only _now_ are they finding that we broke
it without even the courtesy of a warning, let alone any consultation.

If _we_ had done it right, then they would have been warned when we
decided to change this, and we wouldn't have just released 2.6.19 with
changes which break the glibc build.

--
dwmw2

Reply | Threaded
Open this post in threaded view
|

Re: Kernel header changes break glibc build

Jakub Jelinek
On Wed, Dec 06, 2006 at 01:01:54PM +0000, David Woodhouse wrote:
> No. They _are_ doing it right -- they're running 'make headers_install'
> against the 2.6.19 kernel and only _now_ are they finding that we broke
> it without even the courtesy of a warning, let alone any consultation.
>
> If _we_ had done it right, then they would have been warned when we
> decided to change this, and we wouldn't have just released 2.6.19 with
> changes which break the glibc build.

Yeah, I don't think glibc was doing anything wrong and the 2.6.19
changes to the make headers_install created headers mean we'd
either need to add configure checks for the headers (we can't
simply #include <linux/if_addr.h> because that header didn't
exist pre 2.6.19 and IF*_{RTA,PAYLOAD} macros were dropped anyway),
or we need to start defining this ourselves.

Here is the second variant.
I just hope further kernel header "cleanups" don't cause similar
breakage though.

2006-12-06  Jakub Jelinek  <[hidden email]>

        * sysdeps/unix/sysv/linux/netlinkaccess.h (struct ifaddrmsg): New type.
        (IFA_UNSPEC, IFA_ADDRESS, IFA_LOCAL, IFA_LABEL, IFA_BROADCAST,
        IFA_ANYCAST, IFA_CACHEINFO, IFA_MULTICAST): New enum.
        (IFA_F_SECONDARY, IFA_F_TEMPORARY, IFA_F_HOMEADDRESS,
        IFA_F_DEPRECATED): Define if not defined.
        (IFA_RTA, IFA_PAYLOAD, IFLA_RTA, IFLA_PAYLOAD): Likewise.
        * sysdeps/unix/sysv/linux/check_pf.c: Include netlinkaccess.h
        instead of asm/types.h, linux/netlink.h and linux/rtnetlink.h.

--- libc/sysdeps/unix/sysv/linux/netlinkaccess.h.jj 2006-01-08 09:21:15.000000000 +0100
+++ libc/sysdeps/unix/sysv/linux/netlinkaccess.h 2006-12-06 13:48:50.000000000 +0100
@@ -25,6 +25,51 @@
 
 #include <kernel-features.h>
 
+/* 2.6.19 kernel headers helpfully removed some macros and
+   moved lots of stuff into new headers, some of which aren't
+   included by linux/rtnetlink.h.  */
+
+#ifndef IFA_MAX
+struct ifaddrmsg
+{
+  uint8_t ifa_family;
+  uint8_t ifa_prefixlen;
+  uint8_t ifa_flags;
+  uint8_t ifa_scope;
+  uint32_t ifa_index;
+};
+
+enum
+{
+  IFA_UNSPEC,
+  IFA_ADDRESS,
+  IFA_LOCAL,
+  IFA_LABEL,
+  IFA_BROADCAST,
+  IFA_ANYCAST,
+  IFA_CACHEINFO,
+  IFA_MULTICAST
+};
+#endif
+
+#ifndef IFA_F_SECONDARY
+# define IFA_F_SECONDARY 0x01
+# define IFA_F_TEMPORARY IFA_F_SECONDARY
+# define IFA_F_HOMEADDRESS 0x10
+# define IFA_F_DEPRECATED 0x20
+#endif
+
+#ifndef IFA_RTA
+# define IFA_RTA(r) \
+  ((struct rtattr *) ((char *)(r) + NLMSG_ALIGN (sizeof (struct ifaddrmsg))))
+# define IFA_PAYLOAD(n) NLMSG_PAYLOAD (n, sizeof (struct ifaddrmsg))
+#endif
+
+#ifndef IFLA_RTA
+# define IFLA_RTA(r) \
+  ((struct rtattr *) ((char *)(r) + NLMSG_ALIGN (sizeof (struct ifinfomsg))))
+# define IFLA_PAYLOAD(n) NLMSG_PAYLOAD (n, sizeof (struct ifinfomsg))
+#endif
 
 struct netlink_res
 {
--- libc/sysdeps/unix/sysv/linux/check_pf.c.jj 2006-09-24 18:50:22.000000000 +0200
+++ libc/sysdeps/unix/sysv/linux/check_pf.c 2006-12-06 13:54:37.000000000 +0100
@@ -27,13 +27,10 @@
 #include <unistd.h>
 #include <sys/socket.h>
 
-#include <asm/types.h>
-#include <linux/netlink.h>
-#include <linux/rtnetlink.h>
-
 #include <not-cancel.h>
 #include <kernel-features.h>
 
+#include "netlinkaccess.h"
 
 #ifndef IFA_F_TEMPORARY
 # define IFA_F_TEMPORARY IFA_F_SECONDARY


        Jakub
Reply | Threaded
Open this post in threaded view
|

Re: Kernel header changes break glibc build

David Woodhouse-7
On Wed, 2006-12-06 at 14:43 +0100, Jakub Jelinek wrote:

>
> +/* 2.6.19 kernel headers helpfully removed some macros and
> +   moved lots of stuff into new headers, some of which aren't
> +   included by linux/rtnetlink.h.  */
> +
> +#ifndef IFA_MAX
> +struct ifaddrmsg
> +{
> +  uint8_t ifa_family;
> +  uint8_t ifa_prefixlen;
> +  uint8_t ifa_flags;
> +  uint8_t ifa_scope;
> +  uint32_t ifa_index;
> +};
> +
> +enum
> +{
> +  IFA_UNSPEC,
> +  IFA_ADDRESS,
> +  IFA_LOCAL,
> +  IFA_LABEL,
> +  IFA_BROADCAST,
> +  IFA_ANYCAST,
> +  IFA_CACHEINFO,
> +  IFA_MULTICAST
> +};
> +#endif
> +
> +#ifndef IFA_F_SECONDARY
> +# define IFA_F_SECONDARY       0x01
> +# define IFA_F_TEMPORARY       IFA_F_SECONDARY
> +# define IFA_F_HOMEADDRESS     0x10
> +# define IFA_F_DEPRECATED      0x20
> +#endif

This much is still available from the new <linux/if_addr.h> -- you could
include that directly instead of copying it.

--
dwmw2

Reply | Threaded
Open this post in threaded view
|

Re: Kernel header changes break glibc build

Jakub Jelinek
On Wed, Dec 06, 2006 at 01:51:07PM +0000, David Woodhouse wrote:

> On Wed, 2006-12-06 at 14:43 +0100, Jakub Jelinek wrote:
> >
> > +/* 2.6.19 kernel headers helpfully removed some macros and
> > +   moved lots of stuff into new headers, some of which aren't
> > +   included by linux/rtnetlink.h.  */
> > +
> > +#ifndef IFA_MAX
> > +struct ifaddrmsg
> > +{
> > +  uint8_t ifa_family;
> > +  uint8_t ifa_prefixlen;
> > +  uint8_t ifa_flags;
> > +  uint8_t ifa_scope;
> > +  uint32_t ifa_index;
> > +};
> > +
> > +enum
> > +{
> > +  IFA_UNSPEC,
> > +  IFA_ADDRESS,
> > +  IFA_LOCAL,
> > +  IFA_LABEL,
> > +  IFA_BROADCAST,
> > +  IFA_ANYCAST,
> > +  IFA_CACHEINFO,
> > +  IFA_MULTICAST
> > +};
> > +#endif
> > +
> > +#ifndef IFA_F_SECONDARY
> > +# define IFA_F_SECONDARY       0x01
> > +# define IFA_F_TEMPORARY       IFA_F_SECONDARY
> > +# define IFA_F_HOMEADDRESS     0x10
> > +# define IFA_F_DEPRECATED      0x20
> > +#endif
>
> This much is still available from the new <linux/if_addr.h> -- you could
> include that directly instead of copying it.

Yes, but as I said, I'd need to add configure checks for that, using
#include <linux/if_addr.h>
alone breaks build with older headers.
glibc so far managed to build without a single configure check for header
existence, this would be the first place where something like that is
needed.

        Jakub
Reply | Threaded
Open this post in threaded view
|

Re: Kernel header changes break glibc build

Thomas Graf
In reply to this post by Jakub Jelinek
* Jakub Jelinek <[hidden email]> 2006-12-06 14:43

> On Wed, Dec 06, 2006 at 01:01:54PM +0000, David Woodhouse wrote:
> > No. They _are_ doing it right -- they're running 'make headers_install'
> > against the 2.6.19 kernel and only _now_ are they finding that we broke
> > it without even the courtesy of a warning, let alone any consultation.
> >
> > If _we_ had done it right, then they would have been warned when we
> > decided to change this, and we wouldn't have just released 2.6.19 with
> > changes which break the glibc build.
>
> Yeah, I don't think glibc was doing anything wrong and the 2.6.19
> changes to the make headers_install created headers mean we'd
> either need to add configure checks for the headers (we can't
> simply #include <linux/if_addr.h> because that header didn't
> exist pre 2.6.19 and IF*_{RTA,PAYLOAD} macros were dropped anyway),
> or we need to start defining this ourselves.

Are you suggesting that the kernel has to keep macros around which
are of no use to the kernel itself just because glibc uses them?

What's wrong with copying the headers and ship them? Every glibc
release is based on some kernel version anyway and its no problem
to run glibc compiled with a 2.6.19 header set on a 2.6.18 kernel.
Reply | Threaded
Open this post in threaded view
|

Re: Kernel header changes break glibc build

David Woodhouse-7
In reply to this post by Jakub Jelinek
On Wed, 2006-12-06 at 14:57 +0100, Jakub Jelinek wrote:
> Yes, but as I said, I'd need to add configure checks for that, using
> #include <linux/if_addr.h>
> alone breaks build with older headers.

I was thinking that the #ifndef IFA_MAX you already have ought to be
sufficient for that. Or even checking KERNEL_VERSION.

--
dwmw2

Reply | Threaded
Open this post in threaded view
|

Re: Kernel header changes break glibc build

David Woodhouse-7
In reply to this post by Thomas Graf
On Wed, 2006-12-06 at 14:59 +0100, Thomas Graf wrote:
> Are you suggesting that the kernel has to keep macros around which
> are of no use to the kernel itself just because glibc uses them?

No, although in fact that _is_ the only reason we use these horrid __uXX
types rather than proper C datatypes, isn't it?

I'm suggesting that if you want to change things around as you did, you
should make sure the users of those headers adapt to cope. You did fix
the in-kernel users; you neglected to fix glibc -- and as far as I can
tell you didn't even bother to _warn_ glibc folks.

We need to do better than that. The dark ages where we used to toss a
pile of crap over the wall and declare it was someone else's problem are
now behind us, thankfully.

--
dwmw2

Reply | Threaded
Open this post in threaded view
|

Re: Kernel header changes break glibc build

Jakub Jelinek
On Wed, Dec 06, 2006 at 02:07:19PM +0000, David Woodhouse wrote:
> On Wed, 2006-12-06 at 14:59 +0100, Thomas Graf wrote:
> > Are you suggesting that the kernel has to keep macros around which
> > are of no use to the kernel itself just because glibc uses them?
>
> No, although in fact that _is_ the only reason we use these horrid __uXX
> types rather than proper C datatypes, isn't it?

There are the kernel's own headers and kernel ABI headers for userland use.
Until recently the latter has been maintained by various distributions
and manually occassionally updated to sync a little bit with kernel ABI
additions (new syscalls, etc.)., but now, thanks to David, these are
generated from kernel's own headers.  If the macros were part of
such ABI (I don't think these macros were meant to be #ifdef __KERNEL__
and just by omission exported to userland), then if you change
the kernel headers (which of course you can do, that's kernel private
headers), then you IMNSHO should also add magic to make headers_install
to keep the kernel ABI headers for userland headers stable.
Which in this case would mean if you decide rtnetlink.h shouldn't include
the newly added if_addr.h that you add rules for generating the userland
rtnetlink.h such that it will include linux/if_addr.h and define the
macros you intentionally omitted.

        Jakub
Reply | Threaded
Open this post in threaded view
|

Re: Kernel header changes break glibc build

Thomas Graf
In reply to this post by David Woodhouse-7
* David Woodhouse <[hidden email]> 2006-12-06 14:07
> On Wed, 2006-12-06 at 14:59 +0100, Thomas Graf wrote:
> > Are you suggesting that the kernel has to keep macros around which
> > are of no use to the kernel itself just because glibc uses them?
>
> No, although in fact that _is_ the only reason we use these horrid __uXX
> types rather than proper C datatypes, isn't it?

Alright, so we agree that there must be a possibility of getting rid of
deprecated crap which leads to interface abusage.

Fixing things is as simple as #ifndef IFA_MAX respectively IFLA_RTA in
some compat header.

> I'm suggesting that if you want to change things around as you did, you
> should make sure the users of those headers adapt to cope. You did fix
> the in-kernel users; you neglected to fix glibc -- and as far as I can
> tell you didn't even bother to _warn_ glibc folks.

I didn't warn them because I didn't know better. I was under the
impression that glibc still maintains their own set of headers
and will fix this automatically when they look at the diff. That's
what I do for my userspace applications that use kernel headers.

Ideally install_headers would do the trick but it often fails f.e.
when some application which uses bsd features thus including net/if.h
also wants to use new linux features and includes linux/if.h which
then conflicts.
Reply | Threaded
Open this post in threaded view
|

Re: Kernel header changes break glibc build

Thomas Graf
In reply to this post by Jakub Jelinek
* Jakub Jelinek <[hidden email]> 2006-12-06 15:18
> There are the kernel's own headers and kernel ABI headers for userland use.
> Until recently the latter has been maintained by various distributions
> and manually occassionally updated to sync a little bit with kernel ABI
> additions (new syscalls, etc.)., but now, thanks to David, these are
> generated from kernel's own headers.  If the macros were part of
> such ABI

Macros can't possibly be part of an ABI :-) You probably mean API.

> (I don't think these macros were meant to be #ifdef __KERNEL__
> and just by omission exported to userland), then if you change
> the kernel headers (which of course you can do, that's kernel private
> headers), then you IMNSHO should also add magic to make headers_install
> to keep the kernel ABI headers for userland headers stable.

At the time they were added they were meant to be exported but netlink
has evolved and we now have a type safe API. Guess what, I'm going to
remove more bits of the old interface because they are no longer needed.

> Which in this case would mean if you decide rtnetlink.h shouldn't include
> the newly added if_addr.h that you add rules for generating the userland
> rtnetlink.h such that it will include linux/if_addr.h and define the
> macros you intentionally omitted.

Sure, moving these bits to some compat header which gets automatically
included by make install_headers instead of removing them sounds
like a good compromise, it just has to be clear that they are deprecated
and not supposed to be used by new code.
Reply | Threaded
Open this post in threaded view
|

Re: Kernel header changes break glibc build

Al Viro-3
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...
Reply | Threaded
Open this post in threaded view
|

Re: Kernel header changes break glibc build

Stefan Rompf
In reply to this post by Thomas Graf
Am Montag, 4. Dezember 2006 10:13 schrieb Thomas Graf:

> 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.

According to a user's report, your change also broke compilation of my
dhcpclient because it neeeds if_addr.h since 2.6.19. Any suggestion how to
make one source code build on 2.6.19 and older headers? I hope you don't want
me to check on UTS_RELEASE in a userspace program?

Stefan
Reply | Threaded
Open this post in threaded view
|

Re: Kernel header changes break glibc build

Thomas Graf
* Stefan Rompf <[hidden email]> 2006-12-06 20:32
> According to a user's report, your change also broke compilation of my
> dhcpclient because it neeeds if_addr.h since 2.6.19. Any suggestion how to
> make one source code build on 2.6.19 and older headers? I hope you don't want
> me to check on UTS_RELEASE in a userspace program?

#ifndef IFA_MAX
#include <linux/if_addr.h>
#endif
Reply | Threaded
Open this post in threaded view
|

Re: Kernel header changes break glibc build

Thomas Graf
In reply to this post by Al Viro-3
* Al Viro <[hidden email]> 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

I'm removing the old bits as soon as I've finished converting all
its users.

An almost identical interface is provided to userspace by libnl.
Reply | Threaded
Open this post in threaded view
|

Re: Kernel header changes break glibc build

Al Viro-3
On Wed, Dec 06, 2006 at 09:26:39PM +0100, Thomas Graf wrote:

> * Al Viro <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Kernel header changes break glibc build

Thomas Graf
* Al Viro <[hidden email]> 2006-12-06 20:34

> On Wed, Dec 06, 2006 at 09:26:39PM +0100, Thomas Graf wrote:
> > * Al Viro <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Kernel header changes break glibc build

David Miller-13
In reply to this post by Stefan Rompf
From: Stefan Rompf <[hidden email]>
Date: Wed, 6 Dec 2006 20:32:40 +0100 (MET)

> Am Montag, 4. Dezember 2006 10:13 schrieb Thomas Graf:
>
> > 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.
>
> According to a user's report, your change also broke compilation of my
> dhcpclient because it neeeds if_addr.h since 2.6.19. Any suggestion how to
> make one source code build on 2.6.19 and older headers? I hope you don't want
> me to check on UTS_RELEASE in a userspace program?

That's enough for me.

Thomas we need to restore things to how they were before.
If that means including if_addr.h from rtnetlink.h so be it.

We can't break shit like this, there are no excuses, especially
now that we properly frob the headers for userspace consumption
in the kernel tree.

Before you hit the reply button, read me again, there are no excuses
for this breakage we've caused.  We must fix it now.

Thanks.
123