On Friday 18 January 2013 09:36:35 Pedro Alves wrote:
On 01/18/2013 02:24 PM, YOSHIFUJI Hideaki wrote:
It's simple enough to move all of the __GLIBC__ uses into
libc-compat.h, then you control userspace libc coordination from one
file.
How about just deciding on a single macro/symbol
On 01/18/2013 04:22 AM, Carlos O'Donell wrote:
On Thu, Jan 17, 2013 at 11:20 PM, Mike Frysinger vap...@gentoo.org wrote:
On Wednesday 16 January 2013 22:15:38 David Miller wrote:
From: Carlos O'Donell car...@systemhalted.org
Date: Wed, 16 Jan 2013 21:15:03 -0500
+/* If a glibc-based
On 01/18/2013 05:44 AM, Pedro Alves wrote:
On 01/18/2013 04:22 AM, Carlos O'Donell wrote:
On Thu, Jan 17, 2013 at 11:20 PM, Mike Frysinger vap...@gentoo.org wrote:
On Wednesday 16 January 2013 22:15:38 David Miller wrote:
From: Carlos O'Donell car...@systemhalted.org
Date: Wed, 16 Jan 2013
Carlos O'Donell wrote:
On 01/18/2013 05:44 AM, Pedro Alves wrote:
On 01/18/2013 04:22 AM, Carlos O'Donell wrote:
On Thu, Jan 17, 2013 at 11:20 PM, Mike Frysinger vap...@gentoo.org wrote:
On Wednesday 16 January 2013 22:15:38 David Miller wrote:
From: Carlos O'Donell car...@systemhalted.org
On 01/18/2013 02:24 PM, YOSHIFUJI Hideaki wrote:
It's simple enough to move all of the __GLIBC__ uses into libc-compat.h,
then you control userspace libc coordination from one file.
How about just deciding on a single macro/symbol both the
kernel and libc (any libc that needs this) define?
On Fri, Jan 18, 2013 at 9:36 AM, Pedro Alves pal...@redhat.com wrote:
On 01/18/2013 02:24 PM, YOSHIFUJI Hideaki wrote:
It's simple enough to move all of the __GLIBC__ uses into libc-compat.h,
then you control userspace libc coordination from one file.
How about just deciding on a single
On Thursday 2013-01-17 03:05, David Miller wrote:
From: Carlos O'Donell car...@systemhalted.org
Date: Wed, 16 Jan 2013 20:58:47 -0500
So I just went down the rabbit hole, and the further I get the
closer I get to having two exact copies of the same definitions
in both glibc and the kernel and
On Wednesday 16 January 2013 16:45:11 David Miller wrote:
What would be really nice is if GCC treated multiple identical
definitions of structures the same way it handles multiple identical
definitions of CPP defines. Which is to silently accept them.
But that's not the case, so we need a
On 01/16/2013 10:22 PM, YOSHIFUJI Hideaki wrote:
Carlos O'Donell wrote:
diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
index f79c372..a2b16a5 100644
--- a/include/uapi/linux/in6.h
+++ b/include/uapi/linux/in6.h
@@ -23,6 +23,13 @@
#include linux/types.h
+/* If a
On Wednesday 16 January 2013 22:15:38 David Miller wrote:
From: Carlos O'Donell car...@systemhalted.org
Date: Wed, 16 Jan 2013 21:15:03 -0500
+/* If a glibc-based userspace has already included in.h, then we will
not + * define in6_addr (nor the defines), sockaddr_in6, or ipv6_mreq.
The
On Thu, Jan 17, 2013 at 11:20 PM, Mike Frysinger vap...@gentoo.org wrote:
On Wednesday 16 January 2013 22:15:38 David Miller wrote:
From: Carlos O'Donell car...@systemhalted.org
Date: Wed, 16 Jan 2013 21:15:03 -0500
+/* If a glibc-based userspace has already included in.h, then we will
not
On Thursday 17 January 2013 23:22:26 Carlos O'Donell wrote:
On Thu, Jan 17, 2013 at 11:20 PM, Mike Frysinger vap...@gentoo.org wrote:
On Wednesday 16 January 2013 22:15:38 David Miller wrote:
From: Carlos O'Donell car...@systemhalted.org
Date: Wed, 16 Jan 2013 21:15:03 -0500
+/* If a
From: Mike Frysinger vap...@gentoo.org
Date: Thu, 17 Jan 2013 23:14:31 -0500
the kernel already exports many types with a __kernel_ prefix. i changed the
kernel headers in Gentoo for a few releases (2.6.28 - 2.6.34) to do the same
thing to pretty much all the networking headers. a few
On Thursday 17 January 2013 23:55:24 David Miller wrote:
From: Mike Frysinger vap...@gentoo.org
the kernel already exports many types with a __kernel_ prefix. i changed
the kernel headers in Gentoo for a few releases (2.6.28 - 2.6.34) to do
the same thing to pretty much all the networking
Cong Wang wrote:
(Cc'ing some glibc developers...)
Hello,
In glibc source file inet/netinet/in.h and kernel source file
include/uapi/linux/in6.h, both define struct in6_addr, and both are
visible to user applications. Thomas reported a conflict below.
So, how can we handle this? /me is
On Wed, 2013-01-16 at 23:21 +0900, YOSHIFUJI Hideaki wrote:
Cong Wang wrote:
(Cc'ing some glibc developers...)
Hello,
In glibc source file inet/netinet/in.h and kernel source file
include/uapi/linux/in6.h, both define struct in6_addr, and both are
visible to user applications.
On Wednesday 16 January 2013 10:47:12 Ben Hutchings wrote:
On Wed, 2013-01-16 at 23:21 +0900, YOSHIFUJI Hideaki wrote:
Cong Wang wrote:
(Cc'ing some glibc developers...)
Hello,
In glibc source file inet/netinet/in.h and kernel source file
include/uapi/linux/in6.h, both
On Wed, 2013-01-16 at 12:04 -0500, Mike Frysinger wrote:
On Wednesday 16 January 2013 10:47:12 Ben Hutchings wrote:
On Wed, 2013-01-16 at 23:21 +0900, YOSHIFUJI Hideaki wrote:
Cong Wang wrote:
(Cc'ing some glibc developers...)
Hello,
In glibc source file
On Wednesday 16 January 2013 12:10:11 Ben Hutchings wrote:
On Wed, 2013-01-16 at 12:04 -0500, Mike Frysinger wrote:
On Wednesday 16 January 2013 10:47:12 Ben Hutchings wrote:
On Wed, 2013-01-16 at 23:21 +0900, YOSHIFUJI Hideaki wrote:
Cong Wang wrote:
(Cc'ing some glibc
From: Mike Frysinger vap...@gentoo.org
Date: Wed, 16 Jan 2013 12:04:56 -0500
certainly true, but the current expectation is that you don't mix your ABIs.
if you're programming with the C library API, then use the C library headers.
if you're banging directly on the kernel, then use the
From: Mike Frysinger vap...@gentoo.org
Date: Wed, 16 Jan 2013 12:28:39 -0500
if you're not calling the kernel directly, why are you including the kernel
headers ? what is the problem people are actually trying to address here
(and
no, i want to include both headers is not the answer) ?
On Wednesday 16 January 2013 13:59:59 David Miller wrote:
From: Mike Frysinger vap...@gentoo.org
if you're not calling the kernel directly, why are you including the
kernel headers ? what is the problem people are actually trying to
address here (and no, i want to include both headers is
From: Mike Frysinger vap...@gentoo.org
Date: Wed, 16 Jan 2013 14:22:16 -0500
On Wednesday 16 January 2013 13:59:59 David Miller wrote:
This has been done for decades, wake up.
and it's been broken for just as long. no need to be a dick.
By being ignorant and having such a simplistic view
On Wednesday 16 January 2013 13:57:44 David Miller wrote:
From: Mike Frysinger vap...@gentoo.org
certainly true, but the current expectation is that you don't mix your
ABIs. if you're programming with the C library API, then use the C
library headers. if you're banging directly on the
From: Ben Hutchings bhutchi...@solarflare.com
Date: Wed, 16 Jan 2013 15:47:12 +
On Wed, 2013-01-16 at 23:21 +0900, YOSHIFUJI Hideaki wrote:
Cong Wang wrote:
(Cc'ing some glibc developers...)
Hello,
In glibc source file inet/netinet/in.h and kernel source file
On 01/16/2013 04:45 PM, David Miller wrote:
From: Ben Hutchings bhutchi...@solarflare.com
Date: Wed, 16 Jan 2013 15:47:12 +
On Wed, 2013-01-16 at 23:21 +0900, YOSHIFUJI Hideaki wrote:
Cong Wang wrote:
(Cc'ing some glibc developers...)
Hello,
In glibc source file inet/netinet/in.h
From: Carlos O'Donell car...@systemhalted.org
Date: Wed, 16 Jan 2013 20:58:47 -0500
So I just went down the rabbit hole, and the further I get the
closer I get to having two exact copies of the same definitions
in both glibc and the kernel and using whichever one was included
first.
Is
On 01/16/2013 01:57 PM, David Miller wrote:
From: Mike Frysinger vap...@gentoo.org
Date: Wed, 16 Jan 2013 12:04:56 -0500
certainly true, but the current expectation is that you don't mix your ABIs.
if you're programming with the C library API, then use the C library
headers.
if
Carlos O'Donell wrote:
diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
index f79c372..a2b16a5 100644
--- a/include/uapi/linux/in6.h
+++ b/include/uapi/linux/in6.h
:
#define IPV6_PRIORITY_14 0x0e00
#define IPV6_PRIORITY_15 0x0f00
+
+#ifndef
From: Carlos O'Donell car...@systemhalted.org
Date: Wed, 16 Jan 2013 21:15:03 -0500
+/* If a glibc-based userspace has already included in.h, then we will not
+ * define in6_addr (nor the defines), sockaddr_in6, or ipv6_mreq. The
+ * ABI used by the kernel and by glibc match exactly. Neither
Carlos O'Donell wrote:
diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
index f79c372..a2b16a5 100644
--- a/include/uapi/linux/in6.h
+++ b/include/uapi/linux/in6.h
@@ -23,6 +23,13 @@
#include linux/types.h
+/* If a glibc-based userspace has already included in.h, then
On Wed, 2013-01-16 at 14:22 -0500, Mike Frysinger wrote:
but this is still too vague. what headers/definitions do people want to see
simultaneously included ? changes would be needed on both sides (kernel C
library).
Hi, Mike,
Please take a look at my first email in this thread. The
On Thu, 2013-01-17 at 11:55 +0800, Jike Song wrote:
On Thu, Jan 17, 2013 at 2:59 AM, David Miller da...@davemloft.net wrote:
When GLIBC doesn't provide it's own definition of some networking
macros or interfaces that the kernel provides, people include the
kernel header.
Recently I
- Original Message -
I see no reason, even although I don't know why it is 46 instead of
40.
Ok, for ::::::255.255.255.255.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
(Cc'ing some glibc developers...)
Hello,
In glibc source file inet/netinet/in.h and kernel source file
include/uapi/linux/in6.h, both define struct in6_addr, and both are
visible to user applications. Thomas reported a conflict below.
So, how can we handle this? /me is wondering why we didn't
35 matches
Mail list logo
