* Re: [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility
[not found] ` <20170420.163630.313375940241598525.davem@davemloft.net>
@ 2017-04-21 13:14 ` Hauke Mehrtens
2017-04-21 13:17 ` David Woodhouse
2017-04-21 14:41 ` Rich Felker
0 siblings, 2 replies; 3+ messages in thread
From: Hauke Mehrtens @ 2017-04-21 13:14 UTC (permalink / raw)
To: David Miller, dwmw2
Cc: netdev, linux-kernel, jarod, jogo, david.heidelberger,
maillist-linux, mikko.rapeli, musl
On 04/20/2017 10:36 PM, David Miller wrote:
> From: David Woodhouse <dwmw2@infradead.org>
> Date: Thu, 20 Apr 2017 21:14:37 +0100
>
>> I agree, except I don't think you're going far enough. Those "standard
>> names" you mention... some of this stuff actually depends on __GLIBC__,
>> and *that* isn't right either.
>
> Yep, that's something that needs correcting.
>
Should all libc implementations define __GLIBC__ or could we at least
switch the kernel UAPI to !__KERNEL__ here?
Hauke
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility
2017-04-21 13:14 ` [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility Hauke Mehrtens
@ 2017-04-21 13:17 ` David Woodhouse
2017-04-21 14:41 ` Rich Felker
1 sibling, 0 replies; 3+ messages in thread
From: David Woodhouse @ 2017-04-21 13:17 UTC (permalink / raw)
To: Hauke Mehrtens, David Miller
Cc: netdev, linux-kernel, jarod, jogo, david.heidelberger,
maillist-linux, mikko.rapeli, musl
[-- Attachment #1: Type: text/plain, Size: 658 bytes --]
On Fri, 2017-04-21 at 15:14 +0200, Hauke Mehrtens wrote:
>
> On 04/20/2017 10:36 PM, David Miller wrote:
> >
> > From: David Woodhouse <dwmw2@infradead.org>
> > Date: Thu, 20 Apr 2017 21:14:37 +0100
> >
> > >
> > > I agree, except I don't think you're going far enough. Those
> > > "standard
> > > names" you mention... some of this stuff actually depends on
> > > __GLIBC__,
> > > and *that* isn't right either.
> > Yep, that's something that needs correcting.
> >
> Should all libc implementations define __GLIBC__ or could we at least
> switch the kernel UAPI to !__KERNEL__ here?
I'd start with the patch I referenced yesterday...
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4938 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Re: [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility
2017-04-21 13:14 ` [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility Hauke Mehrtens
2017-04-21 13:17 ` David Woodhouse
@ 2017-04-21 14:41 ` Rich Felker
1 sibling, 0 replies; 3+ messages in thread
From: Rich Felker @ 2017-04-21 14:41 UTC (permalink / raw)
To: Hauke Mehrtens
Cc: David Miller, dwmw2, netdev, linux-kernel, jarod, jogo,
david.heidelberger, maillist-linux, mikko.rapeli, musl
On Fri, Apr 21, 2017 at 03:14:21PM +0200, Hauke Mehrtens wrote:
>
>
> On 04/20/2017 10:36 PM, David Miller wrote:
> > From: David Woodhouse <dwmw2@infradead.org>
> > Date: Thu, 20 Apr 2017 21:14:37 +0100
> >
> >> I agree, except I don't think you're going far enough. Those "standard
> >> names" you mention... some of this stuff actually depends on __GLIBC__,
> >> and *that* isn't right either.
> >
> > Yep, that's something that needs correcting.
> >
> Should all libc implementations define __GLIBC__
Absolutely not.
Rich
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-04-21 14:41 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20170418210036.26039-1-hauke@hauke-m.de>
[not found] ` <20170420.160739.1263793303398330801.davem@davemloft.net>
[not found] ` <1492719277.8404.16.camel@infradead.org>
[not found] ` <20170420.163630.313375940241598525.davem@davemloft.net>
2017-04-21 13:14 ` [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility Hauke Mehrtens
2017-04-21 13:17 ` David Woodhouse
2017-04-21 14:41 ` Rich Felker
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).