Re: [NETFILTER]: Introduce nf_inet_address

Re: [NETFILTER]: Introduce nf_inet_address

[David Woodhouse]

On Tue, 2008-01-29 at 13:16 +0000, Linux Kernel Mailing List wrote:
> Commit:     643a2c15a407faf08101a20e1a3461160711899d
>
>     [NETFILTER]: Introduce nf_inet_address
>     
>     A few netfilter modules provide their own union of IPv4 and IPv6
>     address storage. Will unify that in this patch series.
>     
>     (1/4): Rename union nf_conntrack_address to union nf_inet_addr and
>     move it to x_tables.h.
>     
>     Signed-off-by: Jan Engelhardt <jengelh@computergmbh.de>
>     Signed-off-by: Patrick McHardy <kaber@trash.net>
>     Signed-off-by: David S. Miller <davem@davemloft.net>

 ...

> --- a/include/linux/netfilter.h
> +++ b/include/linux/netfilter.h
> @@ -48,6 +48,12 @@ enum nf_inet_hooks {
>  	NF_INET_NUMHOOKS
>  };
>  
> +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'.

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

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

-- 
dwmw2

Re: [NETFILTER]: Introduce nf_inet_address

[Patrick McHardy]

[-- 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;

Re: [NETFILTER]: Introduce nf_inet_address

[David Woodhouse]

On Tue, 2008-02-19 at 15:01 +0100, Patrick McHardy wrote:
> 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.

That does the trick -- but are we using u_int32_t elsewhere in
user-visible headers? Does it work there? How?

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

It's in busybox 1.9.1. Just including <netinet/in.h> seems to be
sufficient to make it happy again. I wonder if netfilter.h should
include that for itself?

-- 
dwmw2

Re: [NETFILTER]: Introduce nf_inet_address

[Patrick McHardy]

David Woodhouse wrote:
> On Tue, 2008-02-19 at 15:01 +0100, Patrick McHardy wrote:
>> 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.
> 
> That does the trick -- but are we using u_int32_t elsewhere in
> user-visible headers? Does it work there? How?


Its used in nearly every ip_tables header file. Those are most likely
not included by glibc and iptables includes sys/types.h. Besides
iptables I'm only aware of a perl module that uses these files,
which is probably also including sys/types.h.

>>> 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.
> 
> It's in busybox 1.9.1. Just including <netinet/in.h> seems to be
> sufficient to make it happy again. I wonder if netfilter.h should
> include that for itself?


That would break iptables compilation, which already includes
linux/in.h in some files. I guess the best fix for now is to
include netinet/in.h in busybox and long-term clean this up
properly.

Re: [NETFILTER]: Introduce nf_inet_address

[Jan Engelhardt]

On Feb 19 2008 15:45, Patrick McHardy wrote:
>> 
>> It's in busybox 1.9.1. Just including <netinet/in.h> seems to be
>> sufficient to make it happy again. I wonder if netfilter.h should
>> include that for itself?
>
> That would break iptables compilation, which already includes
> linux/in.h in some files. I guess the best fix for now is to
> include netinet/in.h in busybox and long-term clean this up
> properly.
>

If <linux/netfilter.h> includes <linux/in.h>, userspace compilation
fails (clashing defs, etc.); if <linux/netfilter.h> includes
<netinet/in.h>, kernel compilation fails (file not found).

What comes to mind is the ugly hack we had for a few days:

#ifdef __KERNEL__
#	include <linux/in.h>
#else
#	include <netinet/in.h>
#endif

and I think we should not impose any inclusion rules on userspace
this way.

Right now, it is solved this way:

kernel .c files explicitly include <linux/in.h> when loading
<linux/netfilter.h>,

userspace .c files explicitly includ <netinet/in.h> when loading
<linux/netfilter.h>. And that seems to work out.

Re: [NETFILTER]: Introduce nf_inet_address

[David Woodhouse]

On Tue, 2008-02-19 at 15:45 +0100, Patrick McHardy wrote:
> That would break iptables compilation, which already includes
> linux/in.h in some files. I guess the best fix for now is to
> include netinet/in.h in busybox and long-term clean this up
> properly.

Yeah, that makes sense.

Can we push the change to __u32 (or uint32_t) for 2.6.24? Or is there
something obvious we should be doing in busybox which we aren't? I don't
quite understand why this u_int32_t crap doesn't work at _all_ when it
evidently used to at least in some environments.

-- 
dwmw2

Re: [NETFILTER]: Introduce nf_inet_address

[Patrick McHardy]

David Woodhouse wrote:
> On Tue, 2008-02-19 at 15:45 +0100, Patrick McHardy wrote:
>> That would break iptables compilation, which already includes
>> linux/in.h in some files. I guess the best fix for now is to
>> include netinet/in.h in busybox and long-term clean this up
>> properly.
> 
> Yeah, that makes sense.
> 
> Can we push the change to __u32 (or uint32_t) for 2.6.24? Or is there
> something obvious we should be doing in busybox which we aren't? I don't
> quite understand why this u_int32_t crap doesn't work at _all_ when it
> evidently used to at least in some environments.


I already sent it to Dave for 2.6.25 (I assume that what you meant,
it was introduced after 2.6.24), its currently sitting in net-2.6
and should hit Linus' tree next time he pulls from Dave.

Re: [NETFILTER]: Introduce nf_inet_address

[David Woodhouse]

On Thu, 2008-02-21 at 13:00 +0100, Patrick McHardy wrote:
> I already sent it to Dave for 2.6.25 (I assume that what you meant,
> it was introduced after 2.6.24), its currently sitting in net-2.6
> and should hit Linus' tree next time he pulls from Dave.

I actually meant 2.6.24.x, because I thought the offending patch was in
2.6.24. I didn't realise we were building against post-2.6.24 kernel
headers in Fedora rawhide already. So that'll be fine -- thanks.

-- 
dwmw2

Re: [NETFILTER]: Introduce nf_inet_address

[David Woodhouse]

On Tue, 2008-02-19 at 15:45 +0100, Patrick McHardy wrote:
> That would break iptables compilation, which already includes
> linux/in.h in some files. I guess the best fix for now is to
> include netinet/in.h in busybox and long-term clean this up
> properly.

It looks like iptables is fairly broken anyway:

make[1]: Entering directory `/home/dwmw2/working/extras/iptables/devel/iptables-1.4.0'
Unable to resolve dependency on linux/compiler.h. Try 'make clean'.
Extensions found:
make[1]: Leaving directory `/home/dwmw2/working/extras/iptables/devel/iptables-1.4.0'
error: Bad exit status from /var/tmp/rpm-tmp.32057 (%build)

-- 
dwmw2

Re: [NETFILTER]: Introduce nf_inet_address

[David Woodhouse]

On Fri, 2008-02-22 at 16:52 +0900, David Woodhouse wrote:
> 
> It looks like iptables is fairly broken anyway:
> 
> make[1]: Entering directory
> `/home/dwmw2/working/extras/iptables/devel/iptables-1.4.0'
> Unable to resolve dependency on linux/compiler.h. Try 'make clean'.

And if I move away the contents of the local include/linux/ directory
and replace it with proper headers generated by 'make
headers_install' (which won't be trying to include compiler.h), then I
get more failures:

Unable to resolve dependency on ../include/linux/netfilter/xt_u32.h. Try 'make clean'.
Unable to resolve dependency on linux/netfilter/xt_time.h. Try 'make clean'.
Unable to resolve dependency on linux/netfilter/xt_quota.h. Try 'make clean'.
Unable to resolve dependency on ../include/linux/netfilter/xt_connlimit.h. Try 'make clean'.
Unable to resolve dependency on linux/netfilter_ipv6/ip6t_mh.h. Try 'make clean'.
Unable to resolve dependency on linux/netfilter/nf_nat.h. Try 'make clean'.

In file included from include/linux/netfilter/xt_conntrack.h:10,
                 from extensions/../include/linux/netfilter_ipv4/ipt_conntrack.h:9,
                 from extensions/libipt_conntrack.c:15:
/usr/include/linux/in.h:26: error: redeclaration of enumerator ‘IPPROTO_IP’
/usr/include/netinet/in.h:34: error: previous definition of ‘IPPROTO_IP’ was here

-- 
dwmw2

Re: [NETFILTER]: Introduce nf_inet_address

[Patrick McHardy]

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

David Woodhouse wrote:
> On Tue, 2008-02-19 at 15:45 +0100, Patrick McHardy wrote:
>> That would break iptables compilation, which already includes
>> linux/in.h in some files. I guess the best fix for now is to
>> include netinet/in.h in busybox and long-term clean this up
>> properly.
> 
> It looks like iptables is fairly broken anyway:
> 
> make[1]: Entering directory `/home/dwmw2/working/extras/iptables/devel/iptables-1.4.0'
> Unable to resolve dependency on linux/compiler.h. Try 'make clean'.
> Extensions found:
> make[1]: Leaving directory `/home/dwmw2/working/extras/iptables/devel/iptables-1.4.0'
> error: Bad exit status from /var/tmp/rpm-tmp.32057 (%build)


Yes, that was a bug in the lastest release. We need to
release a 1.4.1 version or something like that, but I'm
not too familiar with the release process, so I haven't
done this so far.

Anyway, I just committed this patch to iptables to remove
the compiler.h inclusions.


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

Index: include/linux/netfilter_ipv6/ip6_tables.h
===================================================================
--- include/linux/netfilter_ipv6/ip6_tables.h	(Revision 7376)
+++ include/linux/netfilter_ipv6/ip6_tables.h	(Arbeitskopie)
@@ -15,7 +15,6 @@
 #ifndef _IP6_TABLES_H
 #define _IP6_TABLES_H
 
-#include <linux/compiler.h>
 #include <linux/netfilter_ipv6.h>
 
 #include <linux/netfilter/x_tables.h>
Index: include/linux/netfilter.h
===================================================================
--- include/linux/netfilter.h	(Revision 7376)
+++ include/linux/netfilter.h	(Arbeitskopie)
@@ -1,8 +1,6 @@
 #ifndef __LINUX_NETFILTER_H
 #define __LINUX_NETFILTER_H
 
-#include <linux/compiler.h>
-
 /* Responses from hook functions. */
 #define NF_DROP 0
 #define NF_ACCEPT 1
Index: include/linux/netfilter_ipv4/ip_tables.h
===================================================================
--- include/linux/netfilter_ipv4/ip_tables.h	(Revision 7376)
+++ include/linux/netfilter_ipv4/ip_tables.h	(Arbeitskopie)
@@ -15,7 +15,6 @@
 #ifndef _IPTABLES_H
 #define _IPTABLES_H
 
-#include <linux/compiler.h>
 #include <linux/netfilter_ipv4.h>
 
 #include <linux/netfilter/x_tables.h>

Re: [NETFILTER]: Introduce nf_inet_address

[Patrick McHardy]

David Woodhouse wrote:
> On Fri, 2008-02-22 at 16:52 +0900, David Woodhouse wrote:
>> It looks like iptables is fairly broken anyway:
>>
>> make[1]: Entering directory
>> `/home/dwmw2/working/extras/iptables/devel/iptables-1.4.0'
>> Unable to resolve dependency on linux/compiler.h. Try 'make clean'.
> 
> And if I move away the contents of the local include/linux/ directory
> and replace it with proper headers generated by 'make
> headers_install' (which won't be trying to include compiler.h), then I
> get more failures:
> 
> Unable to resolve dependency on ../include/linux/netfilter/xt_u32.h. Try 'make clean'.
> Unable to resolve dependency on linux/netfilter/xt_time.h. Try 'make clean'.
> Unable to resolve dependency on linux/netfilter/xt_quota.h. Try 'make clean'.
> Unable to resolve dependency on ../include/linux/netfilter/xt_connlimit.h. Try 'make clean'.
> Unable to resolve dependency on linux/netfilter_ipv6/ip6t_mh.h. Try 'make clean'.
> Unable to resolve dependency on linux/netfilter/nf_nat.h. Try 'make clean'.


Yes, the dependency tracking has always been a bit strange/broken.
The next release will use autoconf, which will hopefully behave
better.

Re: [NETFILTER]: Introduce nf_inet_address

[Pablo Neira Ayuso]

Patrick McHardy wrote:
> Yes, that was a bug in the lastest release. We need to
> release a 1.4.1 version or something like that, but I'm
> not too familiar with the release process, so I haven't
> done this so far.

I can schedule one for this weekend, just send me an ACK.

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers

Re: [NETFILTER]: Introduce nf_inet_address

[Patrick McHardy]

Pablo Neira Ayuso wrote:
> Patrick McHardy wrote:
>> Yes, that was a bug in the lastest release. We need to
>> release a 1.4.1 version or something like that, but I'm
>> not too familiar with the release process, so I haven't
>> done this so far.
> 
> I can schedule one for this weekend, just send me an ACK.


That would be great. I think we had another issue in 1.4.0 with
some header files, but I can't remeber the details.

Jan, I recall we talked about this some time ago, do you remember?

Re: [NETFILTER]: Introduce nf_inet_address

[Jan Engelhardt]

On Feb 22 2008 16:44, Patrick McHardy wrote:
> Pablo Neira Ayuso wrote:
>> Patrick McHardy wrote:
>> > Yes, that was a bug in the lastest release. We need to
>> > release a 1.4.1 version or something like that, but I'm
>> > not too familiar with the release process, so I haven't
>> > done this so far.
>> 
>> I can schedule one for this weekend, just send me an ACK.
>
>
> That would be great. I think we had another issue in 1.4.0 with
> some header files, but I can't remeber the details.
>
> Jan, I recall we talked about this some time ago, do you remember?

I dunno, in Xtables 1.5.1 all header problems (minus
the "uint32_t all" in nf_inet_addr) are resolved I believe.
The thing even compiles without a kernel source now.

Re: [NETFILTER]: Introduce nf_inet_address

[Pablo Neira Ayuso]

Patrick McHardy wrote:
> Pablo Neira Ayuso wrote:
>> Patrick McHardy wrote:
>>> Yes, that was a bug in the lastest release. We need to
>>> release a 1.4.1 version or something like that, but I'm
>>> not too familiar with the release process, so I haven't
>>> done this so far.
>>
>> I can schedule one for this weekend, just send me an ACK.
> 
> 
> That would be great. I think we had another issue in 1.4.0 with
> some header files, but I can't remeber the details.
> 
> Jan, I recall we talked about this some time ago, do you remember?

Was it related with kernel 2.4.x compilation?

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers

Re: [NETFILTER]: Introduce nf_inet_address

[Patrick McHardy]

Pablo Neira Ayuso wrote:
> Patrick McHardy wrote:
>> Pablo Neira Ayuso wrote:
>>> Patrick McHardy wrote:
>>>> Yes, that was a bug in the lastest release. We need to
>>>> release a 1.4.1 version or something like that, but I'm
>>>> not too familiar with the release process, so I haven't
>>>> done this so far.
>>> I can schedule one for this weekend, just send me an ACK.
>>
>> That would be great. I think we had another issue in 1.4.0 with
>> some header files, but I can't remeber the details.
>>
>> Jan, I recall we talked about this some time ago, do you remember?
> 
> Was it related with kernel 2.4.x compilation?


Yes, I just found the old mail, the error was:

In file included from include/linux/netfilter/nf_nat.h:4,
                  from extensions/libipt_DNAT.c:9:
include/linux/netfilter/nf_conntrack_tuple.h:29: error: syntax error 
before "__be32"

Re: [NETFILTER]: Introduce nf_inet_address

[David Woodhouse]

On Fri, 2008-02-22 at 16:44 +0100, Patrick McHardy wrote:
> Pablo Neira Ayuso wrote:
> > Patrick McHardy wrote:
> >> Yes, that was a bug in the lastest release. We need to
> >> release a 1.4.1 version or something like that, but I'm
> >> not too familiar with the release process, so I haven't
> >> done this so far.
> > 
> > I can schedule one for this weekend, just send me an ACK.
> 
> 
> That would be great. I think we had another issue in 1.4.0 with
> some header files, but I can't remeber the details.

If you are going to include header files in the release (which makes a
certain amount of sense), it would be best if those are simply the
result of the kernel's 'make headers_install', without any manual
changes.

-- 
dwmw2

Re: [NETFILTER]: Introduce nf_inet_address

[Patrick McHardy]

David Woodhouse wrote:
> On Fri, 2008-02-22 at 16:44 +0100, Patrick McHardy wrote:
>> Pablo Neira Ayuso wrote:
>>> Patrick McHardy wrote:
>>>> Yes, that was a bug in the lastest release. We need to
>>>> release a 1.4.1 version or something like that, but I'm
>>>> not too familiar with the release process, so I haven't
>>>> done this so far.
>>> I can schedule one for this weekend, just send me an ACK.
>>
>> That would be great. I think we had another issue in 1.4.0 with
>> some header files, but I can't remeber the details.
> 
> If you are going to include header files in the release (which makes a
> certain amount of sense), it would be best if those are simply the
> result of the kernel's 'make headers_install', without any manual
> changes.


Yes, the kernel headers need to be fixed as well to not include
linux/compiler.h outside of #ifdef __KERNEL__. I'll take care
of that.

Re: [NETFILTER]: Introduce nf_inet_address

[David Woodhouse]

On Mon, 2008-02-25 at 13:12 +0100, Patrick McHardy wrote:
> 
> Yes, the kernel headers need to be fixed as well to not include
> linux/compiler.h outside of #ifdef __KERNEL__. I'll take care
> of that.

No. When you run 'make headers_install' that's already taken care of.

-- 
dwmw2

Re: [NETFILTER]: Introduce nf_inet_address

[Patrick McHardy]

David Woodhouse wrote:
> On Mon, 2008-02-25 at 13:12 +0100, Patrick McHardy wrote:
>> Yes, the kernel headers need to be fixed as well to not include
>> linux/compiler.h outside of #ifdef __KERNEL__. I'll take care
>> of that.
> 
> No. When you run 'make headers_install' that's already taken care of.


Right, I missed that. In that case the current headers should match
the kernel headers (with the compiler.h part removed).

Re: [NETFILTER]: Introduce nf_inet_address

[David Woodhouse]

On Mon, 2008-02-25 at 13:20 +0100, Patrick McHardy wrote:
> 
> Right, I missed that. In that case the current headers should match
> the kernel headers (with the compiler.h part removed).

They don't. When you run 'make headers_install' there are some missing.

-- 
dwmw2

Re: [NETFILTER]: Introduce nf_inet_address

[Patrick McHardy]

David Woodhouse wrote:
> On Mon, 2008-02-25 at 13:20 +0100, Patrick McHardy wrote:
>> Right, I missed that. In that case the current headers should match
>> the kernel headers (with the compiler.h part removed).
> 
> They don't. When you run 'make headers_install' there are some missing.


We don't need all of them, but I'll do a proper resync. Thanks.

Re: [NETFILTER]: Introduce nf_inet_address

[David Woodhouse]

On Mon, 2008-02-25 at 13:23 +0100, Patrick McHardy wrote:
> David Woodhouse wrote:
> > On Mon, 2008-02-25 at 13:20 +0100, Patrick McHardy wrote:
> >> Right, I missed that. In that case the current headers should match
> >> the kernel headers (with the compiler.h part removed).
> > 
> > They don't. When you run 'make headers_install' there are some missing.
> 
> 
> We don't need all of them, but I'll do a proper resync. Thanks.

I think we need some of them -- when I just dropped the results of 'make
headers_install' into the iptables build directory, it complained of a
number of them being missing (which I showed a few days ago).

Ideally, the contents of the include/linux/ directory in the iptables
tree would be identical to what you get in usr/include/linux/netfilter*
after running 'make headers_install'.

-- 
dwmw2