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

[Felix Janda <felix.janda@posteo.de>]

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