archive mirror
 help / color / mirror / Atom feed
From: Carlos O'Donell <>
To: Hauke Mehrtens <>,, David Woodhouse <>,
	Felix Janda <>,
Cc: "David S. Miller" <>,
Subject: Re: Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions
Date: Tue, 25 Apr 2017 08:29:00 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 04/25/2017 02:45 AM, Hauke Mehrtens wrote:
> On 03/08/2017 05:39 PM, Carlos O'Donell wrote:
>> Any header needing compat with a libc includes libc-compat.h (per the 
>> documented way the model works). With this patch any included linux kernel
>> header that also includes libc-compat.h would immediately define all 
>> the __UAPI_DEF_* constants to 1 as-if it had defined those structures, 
>> but it has not.
>> For example, with these two patches applied, the inclusion of linux/if.h
>> would define __UAPI_DEF_XATTR to 1, but linux/if.h has not defined
>> XATTR_CREATE or other constants, so a subsequent inclusion sys/xattrs.h
>> from userspace would _not_ define XATTR_CREATE because __UAPI_DEF_XATTR set
>> to 1 indicates the kernel has.
>> I don't want to read into the model you are proposing and would rather you
>> document the semantics clearly so we can all see what you mean.
> What about moving the code from libc-comapt.h into the specific header
> files? This way including linux/if.h would not have an impact on
> __UAPI_DEF_XATTR, because this is defined in linux/xattr.h. We would
> still have a problem when the specific Linux header file gets included
> before the libc header file, but at least musl does not support this anyway.

The point of libc-compat.h is to contain the libc-related logic to a single header
where it can be reviewed easily as a whole for each libc.

Headers that include libc-compat.h need not have any libc-related logic, they need
only guard their structures with the appropriate __UAPI_DEF* macros per the rules
described in libc-compat.h.

This way we minimize any changes to the header files and keep the complex
logic in one place where the libc authors can discuss it.

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.

If musl only needs header coordination in one direction, then support only that
direction, but please do not presume to simplify the code by deleting a bunch of
things that were worked into the kernel to ensure header inclusion ordering works
in both ways.

I have lots of customers writing code that includes kernel headers and letting them
include headers safely in any order where both headers provide the same define is
the simplest thing.

If you have a suggestion, please describe your proposed model in detail, and provide
a patch that explains and show how it works.


  reply	other threads:[~2017-04-25 12:29 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]     ` <>
2017-04-25  6:45       ` [musl] " Hauke Mehrtens
2017-04-25 12:29         ` Carlos O'Donell [this message]
2017-04-25 17:00           ` Rich Felker
     [not found]           ` <>
2017-06-02  7:07             ` [musl] " Florian Weimer
     [not found]   ` <>
2017-04-25  6:37     ` Hauke Mehrtens
     [not found]       ` <9373f78c-ff15-fbb5-724a-27152d6f994b-5/>
2017-04-25 12:13         ` Carlos O'Donell
2017-07-08 20:27           ` Felix Janda
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]     ` <>
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* 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).