Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <13894.132.241.155.160.1349930187.squirrel@lavabit.com>
Date: Thu, 11 Oct 2012 00:36:27 -0400 (EDT)
From: idunham@...abit.com
To: musl@...ts.openwall.com
Subject: Re: Clash between 'netinet/if_ether.h' and 
     'linux/if_ether.h'

> 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

It's in *BSD with a "(c) 1982,... Regents of the University of California"
notice. So it was part of the original BSD networking stack.
glibc has a strange mix of #include <linux/...> & copy-paste from the BSD
headers.

In summary, while it isn't standardized AFAICT, it's part of just about
every *nix version in recent history (AIX, OS X, Solaris, Unixware, SCO
OpenServer, OSF/1, Linux + *libc, Mach, Hurd, and probably a few more). My
best guess is that the kernel developers needed it for the kernel network
stack (hence <linux/if_ether.h>), and the libc developers included that
copy to avoid exactly this issue.

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



Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.