All of lore.kernel.org
 help / color / mirror / Atom feed
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: [musl] 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

WARNING: multiple messages have this Message-ID (diff)
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

  reply	other threads:[~2017-07-08 20:29 UTC|newest]

Thread overview: 28+ 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
2017-04-25  6:45     ` [musl] " Hauke Mehrtens
2017-04-25  6:45       ` Hauke Mehrtens
2017-04-25 12:29       ` Carlos O'Donell
2017-04-25 12:29         ` Carlos O'Donell
2017-04-25 17:00         ` [musl] " Rich Felker
2017-04-25 17:00           ` Rich Felker
2017-06-02  7:07         ` [musl] " Florian Weimer
2017-06-02  7:07           ` Florian Weimer
2017-04-25  6:37   ` Hauke Mehrtens
2017-04-25  6:37     ` Hauke Mehrtens
2017-04-25 12:13     ` Carlos O'Donell
2017-04-25 12:13       ` Carlos O'Donell
2017-07-08 20:27       ` Felix Janda [this message]
2017-07-08 20:27         ` Felix Janda
2017-03-08 15:53 ` Carlos O'Donell
2017-03-08 16:25   ` [musl] " Rich Felker
2017-03-08 16:25     ` Rich Felker
2017-03-08 17:29     ` [musl] " Carlos O'Donell
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       ` [musl] " Rich Felker
2017-03-09  2:01         ` Rich Felker
2017-04-25 13:22     ` Florian Weimer
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.