From: Mikko Rapeli <mikko.rapeli@iki.fi>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Hauke Mehrtens <hauke@hauke-m.de>,
davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, jarod@redhat.com, jogo@openwrt.org,
david.heidelberger@ixit.cz, maillist-linux@barfooze.de
Subject: Re: [PATCH 3/4] uapi glibc compat: Do not check for __USE_MISC
Date: Thu, 16 Mar 2017 10:26:44 +0200 [thread overview]
Message-ID: <20170316082644.GD8672@lakka.kapsi.fi> (raw)
In-Reply-To: <1489651152.4195.192.camel@infradead.org>
On Thu, Mar 16, 2017 at 07:59:12AM +0000, David Woodhouse wrote:
> On Sun, 2017-03-12 at 23:00 +0100, Hauke Mehrtens wrote:
> > __USE_MISC is glibc specific and not available in musl libc. Only do
> > this check when glibc is used. This fixes a problem with musl libc.
> > ...
> > -/* Coordinate with glibc net/if.h header. */
> > -#if defined(_NET_IF_H) && defined(__USE_MISC)
> > +/* Coordinate with libc net/if.h header. */
> > +#if defined(_NET_IF_H) && (!defined(__GLIBC__) || defined(__USE_MISC))
>
> I *really* don't like building up a plethora of knowledge about
> specific libc implementations in the kernel. As a general rule, if we
> have *anything* that depends on __GLIBC__ then we are Doing It Wrong™.
Kernel does not depend on glibc but uapi headers check for some defintions
so that userspace code can include both libc and kernel header files
without compiler errors.
This interface between kernel and libc header files is messy due to long
history of copying header files from kernel to libc implementations etc
and thus this kind of ifdef magic with in depth knowledge of various
libc's defintions is currently unavoidable.
-Mikko
next prev parent reply other threads:[~2017-03-16 8:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-12 22:00 [PATCH 0/4] uapi glibc compat: fix musl libc compatibility Hauke Mehrtens
2017-03-12 22:00 ` [PATCH 1/4] uapi glibc compat: add libc compat code when not build for kernel Hauke Mehrtens
2017-03-13 11:28 ` Mikko Rapeli
2017-03-12 22:00 ` [PATCH 2/4] uapi glibc compat: fix build if libc defines IFF_ECHO Hauke Mehrtens
2017-03-13 11:28 ` Mikko Rapeli
2017-03-12 22:00 ` [PATCH 3/4] uapi glibc compat: Do not check for __USE_MISC Hauke Mehrtens
2017-03-13 11:29 ` Mikko Rapeli
2017-03-16 7:59 ` David Woodhouse
2017-03-16 8:26 ` Mikko Rapeli [this message]
2017-03-17 18:17 ` Hauke Mehrtens
2017-03-12 22:00 ` [PATCH 4/4] uapi/if_ether.h: prevent redefinition of struct ethhdr Hauke Mehrtens
2017-03-13 11:31 ` Mikko Rapeli
2017-03-28 12:01 ` [PATCH 0/4] uapi glibc compat: fix musl libc compatibility Hauke Mehrtens
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=20170316082644.GD8672@lakka.kapsi.fi \
--to=mikko.rapeli@iki.fi \
--cc=davem@davemloft.net \
--cc=david.heidelberger@ixit.cz \
--cc=dwmw2@infradead.org \
--cc=hauke@hauke-m.de \
--cc=jarod@redhat.com \
--cc=jogo@openwrt.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maillist-linux@barfooze.de \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®