Re: nf_conntrack tree

[Patrick McHardy <kaber@trash.net>]

Yasuyuki KOZAKAI wrote:
> Hi, Patrick,
> 
> OK, I agree introducing nf_ct_ops.
> 
> But in the current, it's not acceptable to introduce nf_conntrack_common
> as you said in other mail. I think it needs many changes to ip_conntrack and
> ip_nat, it may be difficult to change nf_conn structure
> (e.g. optimization), and it will confuse us - What we unify is ?

We're unifying things common to ip_conntrack and nf_conntrack, like
mark, status, ... in order to keep the number of accessor functions
in nf_ct_ops to a minimum.

> My suggestion is pulling out common definitions of enum and flags to some
> common header files, and making {ip,nf}_conntrack*.h include them.
> No change to ip_conntrack_*.c is necessary.

Yes, that is one part. But some matches/targets need to get some
information from the conntrack. I've made a list of what is needed, so
we can talk in more concrete terms:

ipt_state:
- recognize untracked

ipt_helper:
- ct->master->helper->name

ipt_conntrack:
- recognize untracked
- tuples
- status
- expires

ipt_connmark/IPT_CONNMARK:
- mark

Creating a struct nf_conntrack_common should be ok for untracked,
status, expires, mark and master->helper->name. The tuples can't be
handled this way, for them we need nf_ct_ops.

Regards
Patrick