[PATCH 00/09]IPtablestng/Kernel - New Framework For IPtables

[PATCH 00/09]IPtablestng/Kernel - New Framework For IPtables

[hamid jafarian]

New Framework for IPtables

beside some powerfull & usefull features of iptables, this framework add this new features to the Iptables:
	1- Use link list for rule storage instead of continues memory.
	2- Move management activities to the kernel side. 
	3- Command base communication between Kernel/User spaces.
	4- New semantics & structures:
		4-1: tables as builtin/userdefined chains container: store them in link list
		4-2: chains as entry container: store them in link list
		4-3: ...
	5- Classifiers as search engine in chains instead of linear search:
			In This Version the Implementation of Classification algorithms Is like of Matches and Targets but doesn.t have User Space implementation. Every chain can use its classifier.
			By this ability (use/implement different classification algorithms), developers/administrators can classify their network packet flows in defferent ways base on the packet types or their needs and also more quickly than before.
	6- Common implementation for all of the tables of different network families(as pkt_tables) instead of copy based code.
	7- ...

this implementation is for kernel 2.6.25 and supports IPv4. 

patch summary:
 A  include/linux/netfilter/pkt_tables.h
 M  include/linux/netfilter/x_tables.h
 M  include/linux/netfilter_ipv4/ip_tables.h
 A  include/linux/netfilter_ipv4/ipc_tuple.h
 M  net/ipv4/netfilter/Kconfig
 M  net/ipv4/netfilter/Makefile
 M  net/ipv4/netfilter/ip_tables.c
 A  net/ipv4/netfilter/ipc_tuple.c
 M  net/ipv4/netfilter/ipt_CLUSTERIP.c
 M  net/ipv4/netfilter/ipt_ECN.c
 M  net/ipv4/netfilter/ipt_REJECT.c
 M  net/ipv4/netfilter/iptable_filter.c
 M  net/ipv4/netfilter/iptable_mangle.c
 M  net/ipv4/netfilter/iptable_raw.c
 M  net/ipv4/netfilter/nf_nat_rule.c
 M  net/netfilter/Kconfig
 M  net/netfilter/Makefile
 A  net/netfilter/pkt_tables.c
 M  net/netfilter/x_tables.c
 
 include/linux/netfilter/pkt_tables.h     |  542 +++++++
 include/linux/netfilter/x_tables.h       |   15 +
 include/linux/netfilter_ipv4/ip_tables.h |  231 +---
 include/linux/netfilter_ipv4/ipc_tuple.h |   69 +
 net/ipv4/netfilter/Kconfig               |   13 +
 net/ipv4/netfilter/Makefile              |    3 +
 net/ipv4/netfilter/ip_tables.c           | 2356 +++---------------------------
 net/ipv4/netfilter/ipc_tuple.c           |  300 ++++
 net/ipv4/netfilter/ipt_CLUSTERIP.c       |   16 +-
 net/ipv4/netfilter/ipt_ECN.c             |    2 +-
 net/ipv4/netfilter/ipt_REJECT.c          |    4 +-
 net/ipv4/netfilter/iptable_filter.c      |   57 +-
 net/ipv4/netfilter/iptable_mangle.c      |   69 +-
 net/ipv4/netfilter/iptable_raw.c         |   55 +-
 net/ipv4/netfilter/nf_nat_rule.c         |   60 +-
 net/netfilter/Kconfig                    |    8 +
 net/netfilter/Makefile                   |    1 +
 net/netfilter/pkt_tables.c               | 2203 ++++++++++++++++++++++++++++
 net/netfilter/x_tables.c                 |   14 +-
 19 files changed, 3442 insertions(+), 2576 deletions(-)

Re: [PATCH 00/09]IPtablestng/Kernel - New Framework For IPtables

[Evgeniy Polyakov]

Hi.

On Mon, Oct 27, 2008 at 07:58:33AM +0330, hamid jafarian (hamid.jafarian@gmail.com) wrote:
> New Framework for IPtables

Frankly saying your codying style is way out of expected range of
allowed glitches, so it is quite hard to review the whole thing. Please
update it to at least remotely match existing code. Also I noticed you
do not use list iteration functions sometimes and replaces them with
direct access to next/prev pointers, which is not a good idea.

-- 
	Evgeniy Polyakov

Re: [PATCH 00/09]IPtablestng/Kernel - New Framework For IPtables

[David Miller]

From: Evgeniy Polyakov <zbr@ioremap.net>
Date: Tue, 28 Oct 2008 03:00:44 +0300

> On Mon, Oct 27, 2008 at 07:58:33AM +0330, hamid jafarian (hamid.jafarian@gmail.com) wrote:
> > New Framework for IPtables
> 
> Frankly saying your codying style is way out of expected range of
> allowed glitches, so it is quite hard to review the whole thing. Please
> update it to at least remotely match existing code. Also I noticed you
> do not use list iteration functions sometimes and replaces them with
> direct access to next/prev pointers, which is not a good idea.

And also please remove me from the CC: list as I have zero interest
in these patches.

Thanks.

Re: [PATCH 00/09]IPtablestng/Kernel - New Framework For IPtables

[hamid jafarian]

hi, &  special thanks

On Tue, Oct 28, 2008 at 3:30 AM, Evgeniy Polyakov <zbr@ioremap.net> wrote:
> Frankly saying your codying style is way out of expected range of
> allowed glitches, so it is quite hard to review the whole thing. Please
> update it to at least remotely match existing code.

excuse for this loosely patches...
please more explain...
do you mean my patches are too long? or ambiguous?
i 've tried to code base on "Documentation/CodingStyle".. and patch
base on "how to participate in the kernel community" documents.

the core of this framework is located at pkt_tables.c&.h (#2&#3 of
kernel patches).
iptables.c&.h are completely changed. also at the user space libiptc.c
is rewritten from scratch thus their patches are really ambiguous to
be understood..what is the best way to send this patches?
what this phrase mean: "' remotely match existing code ""?

>Also I noticed you
> do not use list iteration functions sometimes and replaces them with
> direct access to next/prev pointers, which is not a good idea.
ok, i 've used this style to free list elements.
if you mean "don't use direct access to prev/next", i 'll review my
code and will try to use list iteration function on every place that
is possible or at list use list functions and list element of
structures instead of direct access to "next/prev"..

-- 
Hamid Jafarian (hm.t)

Re: [PATCH 00/09]IPtablestng/Kernel - New Framework For IPtables

[Evgeniy Polyakov]

Hi.

On Tue, Oct 28, 2008 at 01:32:06PM +0330, hamid jafarian (hamid.jafarian@gmail.com) wrote:
> excuse for this loosely patches...
> please more explain...
> do you mean my patches are too long? or ambiguous?
> i 've tried to code base on "Documentation/CodingStyle".. and patch
> base on "how to participate in the kernel community" documents.
> 
> the core of this framework is located at pkt_tables.c&.h (#2&#3 of
> kernel patches).
> iptables.c&.h are completely changed. also at the user space libiptc.c
> is rewritten from scratch thus their patches are really ambiguous to
> be understood..what is the best way to send this patches?
> what this phrase mean: "' remotely match existing code ""?

I mean just coding style: spaces, braces, parentheses, function names
like __something_small_AND_CAPITAL. checkpatch.pl may help, although imo
it should not be followed strickly. It will much simpler to review changes.

-- 
	Evgeniy Polyakov

Re: [PATCH 00/09]IPtablestng/Kernel - New Framework For IPtables

[Patrick McHardy]

Evgeniy Polyakov wrote:
> Hi.
> 
> On Tue, Oct 28, 2008 at 01:32:06PM +0330, hamid jafarian (hamid.jafarian@gmail.com) wrote:
>> excuse for this loosely patches...
>> please more explain...
>> do you mean my patches are too long? or ambiguous?
>> i 've tried to code base on "Documentation/CodingStyle".. and patch
>> base on "how to participate in the kernel community" documents.
>>
>> the core of this framework is located at pkt_tables.c&.h (#2&#3 of
>> kernel patches).
>> iptables.c&.h are completely changed. also at the user space libiptc.c
>> is rewritten from scratch thus their patches are really ambiguous to
>> be understood..what is the best way to send this patches?
>> what this phrase mean: "' remotely match existing code ""?
> 
> I mean just coding style: spaces, braces, parentheses, function names
> like __something_small_AND_CAPITAL. checkpatch.pl may help, although imo
> it should not be followed strickly. It will much simpler to review changes.

I think these patches are a lost cause. Besides the fact that they
move things to the kernel instead of to userspace, they

- break the existing interface
- do not use netlink
- are a drop-in replacement instead of incremental changes or a
   completely new implementation
- fix only a very small part of the problems of the current
   iptables design

I've asked Hamid to post these patches to see if there were any
useful incremental changes that would make sense to apply to
iptables, but it seems to come down to moving userspace to kernel
to support incremental changes.

Re: [PATCH 00/09]IPtablestng/Kernel - New Framework For IPtables

[Evgeniy Polyakov]

On Tue, Oct 28, 2008 at 01:07:38PM +0100, Patrick McHardy (kaber@trash.net) wrote:
> I think these patches are a lost cause. Besides the fact that they
> move things to the kernel instead of to userspace, they

What about part which replaces rules array with a list?
That's the main part I was interested in though.

-- 
	Evgeniy Polyakov

Re: [PATCH 00/09]IPtablestng/Kernel - New Framework For IPtables

[Patrick McHardy]

Evgeniy Polyakov wrote:
> On Tue, Oct 28, 2008 at 01:07:38PM +0100, Patrick McHardy (kaber@trash.net) wrote:
>> I think these patches are a lost cause. Besides the fact that they
>> move things to the kernel instead of to userspace, they
> 
> What about part which replaces rules array with a list?
> That's the main part I was interested in though.

Thats also the part that breaks userspace compatibility and requires
to move a lot of userspace code to the kernel, at least in that
design. Its not possible to do this with iptables without breaking
userspace compability.

Re: [PATCH 00/09]IPtablestng/Kernel - New Framework For IPtables

[Evgeniy Polyakov]

On Tue, Oct 28, 2008 at 01:30:11PM +0100, Patrick McHardy (kaber@trash.net) wrote:
> >What about part which replaces rules array with a list?
> >That's the main part I was interested in though.
> 
> Thats also the part that breaks userspace compatibility and requires
> to move a lot of userspace code to the kernel, at least in that
> design. Its not possible to do this with iptables without breaking
> userspace compability.

Ok, I see. Than likely case is closed...

-- 
	Evgeniy Polyakov

Re: [PATCH 00/09]IPtablestng/Kernel - New Framework For IPtables

[hamid jafarian]

hi,
> I think these patches are a lost cause.
may be!!.. and also may not
>Besides the fact that they
> move things to the kernel instead of to userspace, they
just adding/removing.. beside huge efforts in the previous version in
copying/cloning this seems not to be bad effort..

> - break the existing interface
> - do not use netlink
i didn't change any function prototype at the user space, so i think
nothing is break (only the functions implementations at libiptc.c are
changed).. just between kernel and user (this is internal).. and just
for entries structure..
netlink is one of my ideas about this version and may implement..
> - are a drop-in replacement instead of incremental changes or a
>  completely new implementation
by this new idea, many things are changed and wrirten from scratch.. i
can continue its implementation to be completed.
> - fix only a very small part of the problems of the current
>  iptables design
beside your new ideas about nftables, this implementation also has
some new ideas:
about sets in  nftables: we can implement sets as classifier in this version
about registers in nftables: we can see matches as registers in this version
and about multiple targets: this version can use multiple targets..
>
> I've asked Hamid to post these patches to see if there were any
> useful incremental changes that would make sense to apply to
> iptables, but it seems to come down to moving userspace to kernel
> to support incremental changes.
not only user to kernel.. this limited to add/remove..
using classifiers as search engine, common framework for tables and
new semantics.. so on..


-- 
Hamid Jafarian (hm.t)