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

On 03/08/2017 01:46 PM, David Woodhouse wrote:

On Fri, 2016-11-11 at 07:08 -0500, Felix Janda wrote:

quoted

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.

Hauke