mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: Clash between 'netinet/if_ether.h' and 'linux/if_ether.h'
Date: Wed, 10 Oct 2012 20:01:05 -0400	[thread overview]
Message-ID: <20121011000105.GS254@brightrain.aerifal.cx> (raw)
In-Reply-To: <5075D54B.60005@embtoolkit.org>

On Wed, Oct 10, 2012 at 10:06:35PM +0200, Abdoulaye Walsimou GAYE wrote:
> On 10/09/2012 01:33 AM, Rich Felker wrote:
> >On Tue, Oct 09, 2012 at 12:45:17AM +0200, Abdoulaye Walsimou GAYE wrote:
> >>Hello,
> >>While trying to compile busybox-1.20.2, the following issue raised:
> >>
> >>   CC      networking/ifplugd.o
> >>In file included from /home/walsimou/embtoolkit.git/sysroot-armel-linux-arm920t/usr/include/net/ethernet.h:10:0,
> >>                  from networking/ifplugd.c:41:
> >>/home/walsimou/embtoolkit.git/sysroot-armel-linux-arm920t/usr/include/netinet/if_ether.h:75:8: error: redefinition of 'struct ethhdr'
> >>/home/walsimou/embtoolkit.git/sysroot-armel-linux-arm920t/usr/include/linux/if_ether.h:127:8: note: originally defined here
> >>
> >>Note that uClibc strategy here is to include linux/if_ether.h
> >It's a bug to be including linux/if_ether.h, and there's no way to
> >work around this without depending on kernel headers, which musl will
> >not do for two reasons:
> >
> >1. We can't control conformance issues and/or breakage if they expose
> >crap into the namespace that they shouldn't be exposing, and this
> >tends to vary by version.
> >
> >2. It makes it so you can't build or use musl without kernel headers.
> >
> >It should be a one-line patch to fix ifplugd.
> >
> >Rich
> 
> 
> Hi Rich,
> 
> I understand your point to not pollute the namespace, but there is others files
> under linux/ doing #include <linux/if_ether.h>.
> 
> linux/ethtool.h:17:#include <linux/if_ether.h>
> linux/if_tun.h:20:#include <linux/if_ether.h>
> linux/if_bonding.h:48:#include <linux/if_ether.h>
> linux/virtio_net.h:31:#include <linux/if_ether.h>
> linux/netfilter_bridge.h:8:#include <linux/if_ether.h>
> linux/bpqether.h:9:#include <linux/if_ether.h>
> linux/netdevice.h:29:#include <linux/if_ether.h>
> linux/if_fddi.h:12: *        if_fddi.h is based on previous if_ether.h and if_tr.h work by
> linux/if_arcnet.h:20:#include <linux/if_ether.h>
> linux/atmlec.h:13:#include <linux/if_ether.h>
> linux/if_pppox.h:24:#include <linux/if_ether.h>
> linux/if_ether.h:8: * Version:    @(#)if_ether.h    1.0.1a 02/08/94
> linux/netfilter_bridge/ebtables.h:17:#include <linux/if_ether.h>
> 
> 
> Does it means all these files should not be used in userspace
> application beside netinet/if_ether.h?
> Or does it means that these files should not be exported to
> userspace headers or should include
> <netinet/if_ether.h> instead?
> If yes, then It's a bug and should be reported to upstream kernel
> network maintainers.

I think it's a bug that should be reported to the upstream kernel
network maintainers. But I'm not sure what the right fix is. In
general, kernel headers should never define anything that clashes with
userspace headers. However, netinet/if_ether.h is not a "standard"
header by any standard I know of; it seems to have been invented by
glibc (correct me if I'm mistaken). In this case, if I'm right, it may
actually be glibc that trampled namespace belonging to the kernel.

With that said, as the headers currently stand, I think the code bug
is the act of including both netinet/if_ether.h and linux/if_ether.h
(or any other linux/ header that includes linux/if_ether.h). An
application should use _either_ the userspace _or_ the kernel headers
for this extended functionality, not both.

Rich


  reply	other threads:[~2012-10-11  0:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-08 22:45 Abdoulaye Walsimou GAYE
2012-10-08 23:33 ` Rich Felker
2012-10-09 23:13   ` Isaac Dunham
2012-10-09 23:15     ` Rich Felker
2012-10-10  0:08       ` Isaac Dunham
2012-10-10 20:06   ` Abdoulaye Walsimou GAYE
2012-10-11  0:01     ` Rich Felker [this message]
2012-10-11  4:36       ` idunham

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=20121011000105.GS254@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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