[PATCH 3/2] Fix compile with NAT but without modules

[PATCH 3/2] Fix compile with NAT but without modules

[Martin Josefsson]

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

Hi Patrick

Here's another patch to fix compile-errors, this time with NAT but
without modules.
There's a missing 'extern' in ip_conntrack_tftp.h

Please submit this patch to davem for inclusion in 2.6.11

Signed-off-by: Martin Josefsson <gandalf@wlug.westbo.se>

diff -X /home/gandalf/dontdiff.ny -urNp linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack_tftp.h linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack_tftp.h
--- linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack_tftp.h	2005-01-22 15:23:45.000000000 +0100
+++ linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack_tftp.h	2005-01-23 01:31:25.000000000 +0100
@@ -13,7 +13,7 @@ struct tftphdr {
 #define TFTP_OPCODE_ACK		4
 #define TFTP_OPCODE_ERROR	5
 
-unsigned int (*ip_nat_tftp_hook)(struct sk_buff **pskb,
+extern unsigned int (*ip_nat_tftp_hook)(struct sk_buff **pskb,
 				 enum ip_conntrack_info ctinfo,
 				 struct ip_conntrack_expect *exp);
 

-- 
/Martin

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 3/2] Fix compile with NAT but without modules

[Patrick McHardy]

Hi Martin,

Martin Josefsson wrote:

>Hi Patrick
>
>Here's another patch to fix compile-errors, this time with NAT but
>without modules.
>There's a missing 'extern' in ip_conntrack_tftp.h
>
>Please submit this patch to davem for inclusion in 2.6.11
>
I'll apply your patches and push them to Dave tomorrow, bkbkits.com
is unreachable currently so I can't resync my tree.

Regards
Patrick

Re: [PATCH 3/2] Fix compile with NAT but without modules

[David S. Miller]

On Mon, 24 Jan 2005 01:33:47 +0100
Patrick McHardy <kaber@trash.net> wrote:

> I'll apply your patches and push them to Dave tomorrow, bkbkits.com
> is unreachable currently so I can't resync my tree.

To be frank, this is one of several severe fallouts from
Rusty's patches.  I really think they were not ready for
submission when he sent them to me.

It even broke the build if you had modules enabled in any
way.

I'm only mentioning this because it appears that nfsim is
becomming partially a crutch, because I know this is what
Rusty and others use heavily for testing.  Which is fine,
but if your patches break the build in many ways in the
real kernel tree you're relying too heavily on the userland
simulator IMHO.

Re: [PATCH 3/2] Fix compile with NAT but without modules

[Rusty Russell]

On Sun, 2005-01-23 at 20:15 -0800, David S. Miller wrote:
> On Mon, 24 Jan 2005 01:33:47 +0100
> Patrick McHardy <kaber@trash.net> wrote:
> 
> > I'll apply your patches and push them to Dave tomorrow, bkbkits.com
> > is unreachable currently so I can't resync my tree.
> 
> To be frank, this is one of several severe fallouts from
> Rusty's patches.  I really think they were not ready for
> submission when he sent them to me.

Yes.  Harald NAKed some of them, and I did nowhere near enough testing
after I shuffled and reworked them to remove the ones he didn't like.
That's entirely my fault, because I needed to get back to IBM work and
rushed it.  Some of these patches had been sitting around for over a
year, and I know that if I didn't push now it would be another year 8(

> It even broke the build if you had modules enabled in any
> way.
> 
> I'm only mentioning this because it appears that nfsim is
> becomming partially a crutch, because I know this is what
> Rusty and others use heavily for testing.  Which is fine,
> but if your patches break the build in many ways in the
> real kernel tree you're relying too heavily on the userland
> simulator IMHO.

True, nfsim sucks for build testing (eg. you only need one #include),
and you always need "real life" testing (eg. races, complex routing,
etc).  But the worst build breakage was because my .config didn't
include some things, which is my the "real" build test also failed to
find them.

OTOH, without nfsim those patches would never have been completed at
all, due to untestability.  That's why major NAT changes were not done
much earlier: there are too many nasty complex scenarios for someone to
test them all, especially such "unnecessary" cleanup work.

I will admit that I'm learning the hard way when to use nfsim, and when
not to.  For example, looks like the IRC nat helper is broken.  Guess
what: no tests in the testsuite.  (I'm writing one now, expect a "boot
tested" patch RSN).

Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman