From: Hauke Mehrtens <hauke@hauke-m.de>
To: musl@lists.openwall.com, David Woodhouse <dwmw2@infradead.org>,
Felix Janda <felix.janda@posteo.de>,
linux-kernel@vger.kernel.org
Cc: "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: Tue, 25 Apr 2017 08:45:43 +0200 [thread overview]
Message-ID: <21e624b9-7ab1-dcf9-fb1e-c31dd564a283@hauke-m.de> (raw)
In-Reply-To: <459a8faf-4585-5063-3d94-3a1fecfa8289@redhat.com>
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.
Hauke
WARNING: multiple messages have this Message-ID (diff)
From: Hauke Mehrtens <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>
To: musl-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org,
David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
Felix Janda <felix.janda-1KBjaw7Xf1+zQB+pC5nmwQ@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: "David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [musl] Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions
Date: Tue, 25 Apr 2017 08:45:43 +0200 [thread overview]
Message-ID: <21e624b9-7ab1-dcf9-fb1e-c31dd564a283@hauke-m.de> (raw)
In-Reply-To: <459a8faf-4585-5063-3d94-3a1fecfa8289-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
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.
Hauke
next prev parent reply other threads:[~2017-04-25 6:45 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 ` Hauke Mehrtens [this message]
2017-04-25 6:45 ` [musl] " 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
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=21e624b9-7ab1-dcf9-fb1e-c31dd564a283@hauke-m.de \
--to=hauke@hauke-m.de \
--cc=davem@davemloft.net \
--cc=dwmw2@infradead.org \
--cc=felix.janda@posteo.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.