netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: David Woodhouse <dwmw2@infradead.org>
Cc: netdev@vger.kernel.org, Jan Engelhardt <jengelh@computergmbh.de>,
	"David S. Miller" <davem@davemloft.net>,
	varevoka@redhat.com
Subject: Re: [NETFILTER]: Introduce nf_inet_address
Date: Tue, 19 Feb 2008 15:01:33 +0100	[thread overview]
Message-ID: <47BAE13D.4060206@trash.net> (raw)
In-Reply-To: <1203428949.3223.25.camel@shinybook.infradead.org>

[-- Attachment #1: Type: text/plain, Size: 1978 bytes --]

David Woodhouse wrote:
>> +union nf_inet_addr {
>> +	u_int32_t	all[4];
>> +	__be32		ip;
>> +	__be32		ip6[4];
>> +};
>> +
>>  #ifdef __KERNEL__
>>  #ifdef CONFIG_NETFILTER
> 
> This breaks the busybox build:
> 
> CC      ipsvd/tcpudp.o
> In file included from /usr/include/linux/netfilter_ipv4.h:8,
>                  from ipsvd/tcpudp.c:33:
> /usr/include/linux/netfilter.h:40: error: expected specifier-qualifier-list before 'u_int32_t'
> 
> What is this 'u_int32_t' nonsense anyway?
> 
> If a user-visible header is likely to be included by libc directly from
> a 'standard' header, it may not require <stdint.h>. Therefore it should
> use the system-specific types such as '__u32'.

Right, I queued this patch to fix it.

> If it isn't likely to be included by libc, which is the case for
> netfilter, then it might as well just use the proper C types. Those who
> are stuck on C89 or earlier might still prefer to use '__u32' even when
> there's no need for it, but 'u_int32_t' is just silly. I suspect we
> should eradicate it.

Yes, some more consitency would be nice. So far the consensus was
to not use it in new code, but keep using it in subsystems like
netfilter that (almost) consistently use it everywhere.

> I couldn't make busybox work with it --
> __BIT_TYPES_DEFINED__ is defined in <sys/types.h> and prevents the
> definitions of u_int32_t et al from appearing in <linux/types.h>. And if
> I include <linux/types.h> first, other things break.
> 
> A later commit adds struct in_addr and struct in6_addr to this union
> too, which breaks busybox even harder.

Thats odd, the iptables headers have always used struct in_addr and
struct in6_addr in struct ipt_ip/struct ip6t_ip6, which are also
used by userspace. What is "ipsvd/tcpudp.c"? I couldn't find it in
the Debian busybox source.

> How is this supposed to be used in userspace? Or is it even supposed to
> be exposed?

Yes, its meant to replace many self-made "AF-independant" address
representations.

[-- Attachment #2: x --]
[-- Type: text/plain, Size: 709 bytes --]

commit 6f2e68f81457d72bdb14a7ead305a1da06e78893
Author: Patrick McHardy <kaber@trash.net>
Date:   Tue Feb 19 14:54:36 2008 +0100

    [NETFILTER]: Use __u32 in struct nf_inet_addr
    
    As reported by David Woodhouse <dwmw2@infradead.org>, using u_int32_t in
    struct nf_inet_addr breaks the busybox build. Fix by using __u32.
    
    Signed-off-by: Patrick McHardy <kaber@trash.net>

diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h
index d74e79b..b74b615 100644
--- a/include/linux/netfilter.h
+++ b/include/linux/netfilter.h
@@ -51,7 +51,7 @@ enum nf_inet_hooks {
 };
 
 union nf_inet_addr {
-	u_int32_t	all[4];
+	__u32		all[4];
 	__be32		ip;
 	__be32		ip6[4];
 	struct in_addr	in;

  reply	other threads:[~2008-02-19 14:01 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200801291316.m0TDGivY024953@hera.kernel.org>
2008-02-19 13:49 ` [NETFILTER]: Introduce nf_inet_address David Woodhouse
2008-02-19 14:01   ` Patrick McHardy [this message]
2008-02-19 14:30     ` David Woodhouse
2008-02-19 14:45       ` Patrick McHardy
2008-02-20 10:24         ` Jan Engelhardt
2008-02-21 11:52         ` David Woodhouse
2008-02-21 12:00           ` Patrick McHardy
2008-02-21 12:19             ` David Woodhouse
2008-02-22  7:52         ` David Woodhouse
2008-02-22  8:01           ` David Woodhouse
2008-02-22 14:59             ` Patrick McHardy
2008-02-22 14:58           ` Patrick McHardy
2008-02-22 15:38             ` Pablo Neira Ayuso
2008-02-22 15:44               ` Patrick McHardy
2008-02-22 16:03                 ` Jan Engelhardt
2008-02-22 16:08                 ` Pablo Neira Ayuso
2008-02-22 16:12                   ` Patrick McHardy
2008-02-22 22:37                 ` David Woodhouse
2008-02-25 12:12                   ` Patrick McHardy
2008-02-25 12:17                     ` David Woodhouse
2008-02-25 12:20                       ` Patrick McHardy
2008-02-25 12:21                         ` David Woodhouse
2008-02-25 12:23                           ` Patrick McHardy
2008-02-25 12:29                             ` David Woodhouse

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=47BAE13D.4060206@trash.net \
    --to=kaber@trash.net \
    --cc=davem@davemloft.net \
    --cc=dwmw2@infradead.org \
    --cc=jengelh@computergmbh.de \
    --cc=netdev@vger.kernel.org \
    --cc=varevoka@redhat.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 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).