On Wed, 2006-12-06 at 15:23 +0100, Thomas Graf wrote:
> > 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
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Thu, 7 Dec 2006 11:47:21 +0100
> * David Miller <[EMAIL PROTECTED]> 2006-12-06 16:56
> > 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
* David Miller <[EMAIL PROTECTED]> 2006-12-06 16:56
> 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
From: Stefan Rompf <[EMAIL PROTECTED]>
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 fil
* Al Viro <[EMAIL PROTECTED]> 2006-12-06 20:34
> On Wed, Dec 06, 2006 at 09:26:39PM +0100, Thomas Graf wrote:
> > * Al Viro <[EMAIL PROTECTED]> 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 expor
On Wed, Dec 06, 2006 at 09:26:39PM +0100, Thomas Graf wrote:
> * Al Viro <[EMAIL PROTECTED]> 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
* Stefan Rompf <[EMAIL PROTECTED]> 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
* Al Viro <[EMAIL PROTECTED]> 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 on
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
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...
-
To unsubscribe from this l
* Jakub Jelinek <[EMAIL PROTECTED]> 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 sysc
* David Woodhouse <[EMAIL PROTECTED]> 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 rea
On Wed, Dec 06, 2006 at 02:07:19PM +, 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_ th
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 datatype
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
> 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_VERS
On Wed, Dec 06, 2006 at 01:51:07PM +, 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.
* Jakub Jelinek <[EMAIL PROTECTED]> 2006-12-06 14:43
> On Wed, Dec 06, 2006 at 01:01:54PM +, 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 cou
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;
On Wed, Dec 06, 2006 at 01:01:54PM +, 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_
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 ser
* David Woodhouse <[EMAIL PROTECTED]> 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 a
On Fri, 2006-10-06 at 17:20 +, 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
> to provide various definitions, some of which have
> been moved to and some of which have been removed
> al
The kernel headers installed by Linux 2.6.19-rc1 "make
headers_install" do not work for building glibc, because glibc expects
to provide various definitions, some of which have
been moved to and some of which have been removed
altogether.
This kernel patch allows glibc to build again by making r
23 matches
Mail list logo
