From: Felix Janda <felix.janda@posteo.de>
To: Carlos O'Donell <carlos@redhat.com>
Cc: Hauke Mehrtens <hauke@hauke-m.de>,
musl@lists.openwall.com, linux-kernel@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
linux-api@vger.kernel.org
Subject: Re: Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions
Date: Sat, 8 Jul 2017 16:27:28 -0400 [thread overview]
Message-ID: <20170708202728.GA1625@nyan> (raw)
In-Reply-To: <d7624df0-0ea4-aba1-f862-9bac540c972f@redhat.com>
Carlos O'Donell wrote:
> On 04/25/2017 02:37 AM, Hauke Mehrtens wrote:
> >
> >
> > On 03/08/2017 01:46 PM, David Woodhouse wrote:
> >> On Fri, 2016-11-11 at 07:08 -0500, Felix Janda wrote:
> >>> Currently, libc-compat.h detects inclusion of specific glibc headers,
> >>> and defines corresponding _UAPI_DEF_* macros, which in turn are used in
> >>> uapi headers to prevent definition of conflicting structures/constants.
> >>> There is no such detection for other c libraries, for them the
> >>> _UAPI_DEF_* macros are always defined as 1, and so none of the possibly
> >>> conflicting definitions are suppressed.
> >>>
> >>> This patch enables non-glibc c libraries to request the suppression of
> >>> any specific interface by defining the corresponding _UAPI_DEF_* macro
> >>> as 0.
> >>
> >> Ick. It's fairly horrid for kernel headers to be reacting to __GLIBC__
> >> in any way. That's just wrong.
> >>
> >> It makes more sense for C libraries to define the __UAPI_DEF_xxx for
> >> themselves as and when they add their own support for certain things,
> >> and for the kernel not to have incestuous knowledge of them.
> >>
> >> The part you add here in the #else /* !__GLIBC__ */ part is what we
> >> should do at *all* times.
> >>
> >> I understand that we'll want to grandfather in the glibc horridness,
> >> but let's make it clear that that's what it is, by letting it set the
> >> appropriate __UAPI_DEF_xxx macros to zero, and then continue through to
> >> your new part. Something like this (incremental to yours):
> >
> > Felix's and this change and are looking better than my patches here:
> > https://lkml.org/lkml/2017/3/12/235
> >
> > Is someone working on brining this into the mainline kernel?
> >
> > Is it correct that only the comments should be improved?
> > musl only supports including the musl header files before the kernel
> > anyway, I assume that it is not needed to make the kernel uapi code
> > support also the other order.
>
> Please repost to linux-api so other relevant C library authors can review
> the changes and comment on how they might be harmonized.
>From the beginning, this patch was CCed to linux-api. Let me repost
anyway with a new (hopefully clearer) commit message.
> Whether or not you support both inclusion orders, kernel first, or libc first,
> is a property of your libc implementation.
>
> Today glibc aims to support both inclusion orders since we see applications
> with either order, and the ordering should not matter in this case. You either
> get one or the other without needing to know any special rules about header
> ordering.
This patch does not change anything for glibc (or uclibc), it just, in
a not very intrusive way, improves the situation for any other libc.
Felix
next prev parent reply other threads:[~2017-07-08 20:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-11 12:08 [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions Felix Janda
2017-03-08 12:46 ` David Woodhouse
2017-03-08 16:39 ` Carlos O'Donell
[not found] ` <459a8faf-4585-5063-3d94-3a1fecfa8289-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-04-25 6:45 ` [musl] " Hauke Mehrtens
2017-04-25 12:29 ` Carlos O'Donell
2017-04-25 17:00 ` Rich Felker
[not found] ` <9f591383-6e4c-c231-1e5b-68e4b8c16d94-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-06-02 7:07 ` [musl] " Florian Weimer
[not found] ` <1488977188.4347.134.camel-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2017-04-25 6:37 ` Hauke Mehrtens
[not found] ` <9373f78c-ff15-fbb5-724a-27152d6f994b-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
2017-04-25 12:13 ` Carlos O'Donell
2017-07-08 20:27 ` Felix Janda [this message]
2017-03-08 15:53 ` Carlos O'Donell
2017-03-08 16:25 ` Rich Felker
2017-03-08 17:29 ` Carlos O'Donell
2017-03-09 0:14 ` Szabolcs Nagy
2017-03-09 0:51 ` Carlos O'Donell
2017-03-09 2:01 ` Rich Felker
[not found] ` <20170309001435.GJ2082-4P1ElwuDYu6sTnJN9+BGXg@public.gmane.org>
2017-04-25 13:22 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170708202728.GA1625@nyan \
--to=felix.janda@posteo.de \
--cc=carlos@redhat.com \
--cc=davem@davemloft.net \
--cc=hauke@hauke-m.de \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).