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
On Fri, Jan 18, 2013 at 9:36 AM, 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 ma
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
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 wrote:
On Wednesday 16 January 2013 22:15:38 David Miller wrote:
> From: Carlos O'Donell
> Date: Wed, 16 Jan 2013
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 wrote:
>>> On Wednesday 16 January 2013 22:15:38 David Miller wrote:
From: Carlos O'Donell
Date: Wed, 16 Jan 2013 21:15:03 -0500
> +/*
On 01/18/2013 04:22 AM, Carlos O'Donell wrote:
> On Thu, Jan 17, 2013 at 11:20 PM, Mike Frysinger wrote:
>> On Wednesday 16 January 2013 22:15:38 David Miller wrote:
>>> From: Carlos O'Donell
>>> Date: Wed, 16 Jan 2013 21:15:03 -0500
>>>
+/* If a glibc-based userspace has already included in
On Thursday 17 January 2013 23:55:24 David Miller wrote:
> From: Mike Frysinger
> > 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
From: Mike Frysinger
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 packages broke, but
On Thursday 17 January 2013 23:22:26 Carlos O'Donell wrote:
> On Thu, Jan 17, 2013 at 11:20 PM, Mike Frysinger wrote:
> > On Wednesday 16 January 2013 22:15:38 David Miller wrote:
> >> From: Carlos O'Donell
> >> Date: Wed, 16 Jan 2013 21:15:03 -0500
> >>
> >> > +/* If a glibc-based userspace has
On Thu, Jan 17, 2013 at 11:20 PM, Mike Frysinger wrote:
> On Wednesday 16 January 2013 22:15:38 David Miller wrote:
>> From: Carlos O'Donell
>> 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 th
On Wednesday 16 January 2013 22:15:38 David Miller wrote:
> From: Carlos O'Donell
> 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
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
>>
>> +/* If a gl
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
On Thursday 2013-01-17 03:05, David Miller wrote:
>From: Carlos O'Donell
>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 whicheve
- 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
Mo
On Thu, 2013-01-17 at 11:55 +0800, Jike Song wrote:
> On Thu, Jan 17, 2013 at 2:59 AM, David Miller 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 got a
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.
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
>
> +/* If a glibc-based userspace has already included in.h, then we w
From: Carlos O'Donell
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 the kernel
> + * nor
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
>
> +
> +#ifn
On 01/16/2013 01:57 PM, David Miller wrote:
> From: Mike Frysinger
> 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 ba
From: Carlos O'Donell
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 anyone opposed to tha
On 01/16/2013 04:45 PM, David Miller wrote:
> From: Ben Hutchings
> 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: Ben Hutchings
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
>> > include/uapi/linux/in6
On Wednesday 16 January 2013 13:57:44 David Miller wrote:
> From: Mike Frysinger
> > 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
From: Mike Frysinger
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 of the situati
On Wednesday 16 January 2013 13:59:59 David Miller wrote:
> From: Mike Frysinger
> > 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
>
From: Mike Frysinger
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) ?
When GLIBC do
From: Mike Frysinger
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 kernel headers.
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 glib
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 so
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/lin
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 app
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
(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 se
35 matches
Mail list logo
