nf_conntrack thoughts [was Re: [PATCH] Conntrack targets/matches work with nfconntrack]

[Pablo Neira <pablo@eurodev.net>]

Pablo Neira wrote:
> This patch makes work conntrack related matches and targets with both 
> ip_conntrack and nf_conntrack (ipt_state, ipt_CONNMARK, ipt_connmark, 
> ipt_NOTRACK, ipt_conntrack).

I've been having a look at the NAT code and try to figure out how I 
could make it work for both ip_conntrack and nf_conntrack, I don't see 
any obvious yet, I've re-read some mail threads a couple of times. Then 
I happened to think that the key is trying to unify the layout of 
ip_conntrack and nf_conn.

Just a thought, nf_conntrack is meant to replace ip_conntrack. So once 
nf_conntrack gets stable ip_conntrack will disappear. In theory life in 
couple of nf_conntrack and ip_conntrack should be short, right?

Here comes my proposition, why don't we just maintain a nf_conntrack 
tree (without ip_conntrack) and make work matches/targets and ipv4 NAT 
code with it? We can keep both trees in sync (currently we have to do 
such thing anyway) and release a patch that applies to current kernel 
periodically. So brave users could test it and give us feedback.

Once the -nfconntrack tree gets stable enough, push it forward into 
kernel mainline. That way we can spend our time improving nf_conntrack 
and not trying make both share code. This could speed up things.

I think that [ip|nf]_conntrack is not the same problem than ipv4/ipv6 
copy&paste of code.

BTW, I still like Yasuyuki Kozakai's unification patches, since I feel a 
bit unconfortable with all that renamed stuff :)

--
Pablo