All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Carlos O'Donell" <carlos@redhat.com>
To: linux-kernel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	linux-api@vger.kernel.org, musl@lists.openwall.com,
	Rich Felker <dalias@aerifal.cx>
Subject: Re: [PATCH resent] uapi libc compat: allow non-glibc to opt out of uapi definitions
Date: Wed, 8 Mar 2017 10:53:00 -0500	[thread overview]
Message-ID: <a360ec42-33ca-5e89-3d70-3b1c9a011c7f@redhat.com> (raw)
In-Reply-To: <20161111120820.GA435@nyan>

On 11/11/2016 07:08 AM, 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.
> 
> This patch together with the recent musl libc commit
> 
> http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258

Would it be possible to amend the musl patch to define the macros to 1.

A defined or undefined macro is typo prone.

Please see this wiki for examples of the problems it causes:
https://sourceware.org/glibc/wiki/Wundef

Having the UAPI macros always defined and be 0 or 1 allows you to create
tooling to check for problems, while an undefined macro is just that,
either a mistake or the intended value.

> fixes the following compiler errors when <linux/in6.h> is included
> after musl <netinet/in.h>:
> 
> ./linux/in6.h:32:8: error: redefinition of 'struct in6_addr'
> ./linux/in6.h:49:8: error: redefinition of 'struct sockaddr_in6'
> ./linux/in6.h:59:8: error: redefinition of 'struct ipv6_mreq'

Do you have plans for fixing the error when the inclusion order is the other way?

It will require kernel header changes to have each individual kernel header define
the requisite __UAPI_* values to 1 e.g. moving libc-compat.h into the header.

Do you plan to do that in a next step?

> Signed-off-by: Felix Janda <felix.janda@posteo.de>
> ---
> The previous mail misspelled the kernel mailing list. I am sorry for
> this resulting spam.
> 
> There has already been one reply, which is available at
> 
> http://www.openwall.com/lists/musl/2016/11/11/2
> ---
>  include/uapi/linux/libc-compat.h | 52 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/include/uapi/linux/libc-compat.h b/include/uapi/linux/libc-compat.h
> index 44b8a6b..c316725 100644
> --- a/include/uapi/linux/libc-compat.h
> +++ b/include/uapi/linux/libc-compat.h
> @@ -171,42 +171,94 @@
>  #else /* !defined(__GLIBC__) */

Would you please update the lead comment in libc-compat.h explaining this usage
model so glibc and other libc's can follow best practice. Any new usage model
should express how to fix header inclusion ordering in both directions.

>  /* Definitions for if.h */
> +#if !defined(__UAPI_DEF_IF_IFCONF)

Typo prone. Please use #if __UAPI_DEF_IF_IFCONF for all of this.

>  #define __UAPI_DEF_IF_IFCONF 1
> +#endif
> +#if !defined(__UAPI_DEF_IF_IFMAP)
>  #define __UAPI_DEF_IF_IFMAP 1
> +#endif
> +#if !defined(__UAPI_DEF_IFNAMSIZ)
>  #define __UAPI_DEF_IF_IFNAMSIZ 1
> +#endif
> +#if !defined(__UAPI_DEF_IFREQ)
>  #define __UAPI_DEF_IF_IFREQ 1
> +#endif
>  /* Everything up to IFF_DYNAMIC, matches net/if.h until glibc 2.23 */
> +#if !defined(__UAPI_DEF_IF_NET_DEVICE_FLAGS)
>  #define __UAPI_DEF_IF_NET_DEVICE_FLAGS 1
> +#endif
>  /* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO */
> +#if !defined(__UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO)
>  #define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
> +#endif
>  
>  /* Definitions for in.h */
> +#if !defined(__UAPI_DEF_IN_ADDR)
>  #define __UAPI_DEF_IN_ADDR		1
> +#endif
> +#if !defined(__UAPI_DEF_IN_IPPROTO)
>  #define __UAPI_DEF_IN_IPPROTO		1
> +#endif
> +#if !defined(__UAPI_DEF_IN_PKTINFO)
>  #define __UAPI_DEF_IN_PKTINFO		1
> +#endif
> +#if !defined(__UAPI_DEF_IP_MREQ)
>  #define __UAPI_DEF_IP_MREQ		1
> +#endif
> +#if !defined(__UAPI_DEF_SOCKADDR_IN)
>  #define __UAPI_DEF_SOCKADDR_IN		1
> +#endif
> +#if !defined(__UAPI_DEF_IN_CLASS)
>  #define __UAPI_DEF_IN_CLASS		1
> +#endif
>  
>  /* Definitions for in6.h */
> +#if !defined(__UAPI_DEF_IN6_ADDR)
>  #define __UAPI_DEF_IN6_ADDR		1
> +#endif
> +#if !defined(__UAPI_DEF_IN6_ADDR_ALT)
>  #define __UAPI_DEF_IN6_ADDR_ALT		1
> +#endif
> +#if !defined(__UAPI_DEF_SOCKADDR_IN6)
>  #define __UAPI_DEF_SOCKADDR_IN6		1
> +#endif
> +#if !defined(__UAPI_DEF_IPV6_MREQ)
>  #define __UAPI_DEF_IPV6_MREQ		1
> +#endif
> +#if !defined(__UAPI_DEF_IPPROTO_V6)
>  #define __UAPI_DEF_IPPROTO_V6		1
> +#endif
> +#if !defined(__UAPI_DEF_IPV6_OPTIONS)
>  #define __UAPI_DEF_IPV6_OPTIONS		1
> +#endif
> +#if !defined(__UAPI_DEF_IN6_PKTINFO)
>  #define __UAPI_DEF_IN6_PKTINFO		1
> +#endif
> +#if !defined(__UAPI_DEF_IP6_MTUINFO)
>  #define __UAPI_DEF_IP6_MTUINFO		1
> +#endif
>  
>  /* Definitions for ipx.h */
> +#if !defined(__UAPI_DEF_SOCKADDR_IPX)
>  #define __UAPI_DEF_SOCKADDR_IPX			1
> +#endif
> +#if !defined(__UAPI_DEF_IPX_ROUTE_DEFINITION)
>  #define __UAPI_DEF_IPX_ROUTE_DEFINITION		1
> +#endif
> +#if !defined(__UAPI_DEF_IPX_INTERFACE_DEFINITION)
>  #define __UAPI_DEF_IPX_INTERFACE_DEFINITION	1
> +#endif
> +#if !defined(__UAPI_DEF_IPX_CONFIG_DATA)
>  #define __UAPI_DEF_IPX_CONFIG_DATA		1
> +#endif
> +#if !defined(__UAPI_DEF_IPX_ROUTE_DEF)
>  #define __UAPI_DEF_IPX_ROUTE_DEF		1
> +#endif
>  
>  /* Definitions for xattr.h */
> +#if !defined(__UAPI_DEF_XATTR)
>  #define __UAPI_DEF_XATTR		1
> +#endif
>  
>  #endif /* __GLIBC__ */
>  
> 

-- 
Cheers,
Carlos.

  parent reply	other threads:[~2017-03-08 16:01 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
2017-07-08 20:27         ` Felix Janda
2017-03-08 15:53 ` Carlos O'Donell [this message]
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=a360ec42-33ca-5e89-3d70-3b1c9a011c7f@redhat.com \
    --to=carlos@redhat.com \
    --cc=dalias@aerifal.cx \
    --cc=davem@davemloft.net \
    --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.