linux-kernel - Re: [musl] Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <74e5c515-d924-c4d8-69ad-aeb57d1c4ef0@redhat.com>
Date:   Fri, 2 Jun 2017 09:07:26 +0200
From:   Florian Weimer <fweimer@...hat.com>
To:     Carlos O'Donell <carlos@...hat.com>,
        Hauke Mehrtens <hauke@...ke-m.de>, musl@...ts.openwall.com,
        David Woodhouse <dwmw2@...radead.org>,
        Felix Janda <felix.janda@...teo.de>,
        linux-kernel@...r.kernel.org
Cc:     "David S. Miller" <davem@...emloft.net>, linux-api@...r.kernel.org
Subject: Re: [musl] Re: [PATCH resent] uapi libc compat: allow non-glibc to
 opt out of uapi definitions

On 04/25/2017 02:29 PM, Carlos O'Donell wrote:
> In glibc right now we support including linux or glibc header files first,
> and this has always been a requirement from the start. This requirement dictates
> that the kernel know which libc it's being used with so it can tailor coordination.

“right now we support” is not a support commitment, but more of an
aspiration, right?

A lot of combinations are broken, especially when kernel headers are
included first.  Maybe it's time for us to admit defeat and come up with
a simpler scheme which actually works.

Thanks,
Florian