Mike Frysinger wrote:
all this stuff is ABI constants, and the only reason glibc
doesn't use them is that glibc prefers to use enums over #defines.
a proper libc defines things in their headers according to the POSIX specs
rather than relying on others to do it for them. if you want to argue
On Friday 11 January 2008, H. Peter Anvin wrote:
Mike Frysinger wrote:
all this stuff is ABI constants, and the only reason glibc
doesn't use them is that glibc prefers to use enums over #defines.
a proper libc defines things in their headers according to the POSIX
specs rather than
On Friday 11 January 2008, Mike Frysinger wrote:
On Friday 11 January 2008, H. Peter Anvin wrote:
Again, I don't particularly care about what they're named, but the whole
point is
#include linux/foo.h
if you want the subset and
#include linux/bar.h
if you want the
From: H. Peter Anvin [EMAIL PROTECTED]
Date: Wed, 02 Jan 2008 10:09:56 -0800
Seems the most logical thing to do would be to break out the small
portion that everyone wants into linux/sockaddr.h or somesuch, and
then remove those ifdefs entirely.
Proposed patch (still being tested)
On Friday 11 January 2008, David Miller wrote:
From: H. Peter Anvin [EMAIL PROTECTED]
Seems the most logical thing to do would be to break out the small
portion that everyone wants into linux/sockaddr.h or somesuch, and
then remove those ifdefs entirely.
Proposed patch (still being
Mike Frysinger wrote:
On Friday 11 January 2008, David Miller wrote:
From: H. Peter Anvin [EMAIL PROTECTED]
Seems the most logical thing to do would be to break out the small
portion that everyone wants into linux/sockaddr.h or somesuch, and
then remove those ifdefs entirely.
Proposed patch
From: Mike Frysinger [EMAIL PROTECTED]
Date: Fri, 11 Jan 2008 01:23:37 -0500
On Friday 11 January 2008, David Miller wrote:
From: H. Peter Anvin [EMAIL PROTECTED]
Seems the most logical thing to do would be to break out the small
portion that everyone wants into linux/sockaddr.h or
David Miller wrote:
Hmmm...
Doesn't glibc include linux/socket.h? If so, before it wouldn't get
the sa_family_t et al. defines (because __GLIBC__ will be defined and
it will be = 2), but with your change it get those things.
Correct me if I'm wrong.
At the moment, yes, it does.
On Friday 11 January 2008, David Miller wrote:
From: Mike Frysinger [EMAIL PROTECTED]
Date: Fri, 11 Jan 2008 01:23:37 -0500
On Friday 11 January 2008, David Miller wrote:
From: H. Peter Anvin [EMAIL PROTECTED]
Seems the most logical thing to do would be to break out the small
Mike Frysinger wrote:
oh, sorry, i see what you mean. i was thinking in terms of crap removed (as
that's what i'm after), not crap added (which is what Peter is after). i
hadnt noticed that. i dont know if it'll break glibc (and really, any other
sane libc). if that is the case, then i
H. Peter Anvin wrote:
Right now, glibc is special-cased. glibc also tends to be very
deliberate about its kernel header inclusions. It wants a subset of the
available defines, so it can include a subset header.
The reverse is definitely possible too -- all other users (kernel,
newlib,
On Friday 11 January 2008, H. Peter Anvin wrote:
Mike Frysinger wrote:
oh, sorry, i see what you mean. i was thinking in terms of crap removed
(as that's what i'm after), not crap added (which is what Peter is
after). i hadnt noticed that. i dont know if it'll break glibc (and
really,
Mike Frysinger wrote:
On Tuesday 01 January 2008, H. Peter Anvin wrote:
Mike Frysinger wrote:
The kernel __GLIBC__ hacks were re-added so as to appease klibc people,
but the klibc people didnt actually fix the problem on their side. This
patch imports the structures/defines that klibc seems
13 matches
Mail list logo
