Re: priv_data patch

[Patrick McHardy <kaber@trash.net>]

Joakim Axelsson wrote:
> 2006-08-14 18:01:19+0200, Patrick McHardy <kaber@trash.net> ->
> 
>>[...]
> 
> I agree. A better solution is needed or no solution at all. However building
> a new API that actually only will change the parts it needs to will need a
> huge amount of work and will most probably break existing userspace. It will
> be very hard to keep backwards compability.

We need to keep the current API stable of course, but that doesn't
prevent us from introducing an entirely new one. Matches and targets
probably can be reused to a certain amount, although I wouldn't
mind getting rid of the excessive amount of matches doing basically
the same thing at the same time.

> As i see it some new hooks are needed on every module to retrieve the kernel
> data. This means we need 5 things:
> 1. start a new rule/match/target (todays checkentry())
> 2. remove an old rule/match/target (todays destroy())
> 3. the worker (todays match() and target())
> 4. A new 'list' that will feed info needed by iptables -L and iptables-save
> to userspace.

Commonly called dump in other netlink interfaces.

> 5. Possible a new 'alter' that will alter info in the rules/match/targets
> private kernel data.

This is tricky to get right on the rule level, a rule consist of
multiple elements that would need to be changed atomically.

> Point 4 and 5 can be views as read and write of the rule. Point 1 and 2 as
> create and destroy.
> 
> A uniq ID will be needed for each rule so userspace can define which rule it
> wishes to alter/remove.

Yes.

> Fairly simple interface to build with netlink. However the real challenge is
> to try to keep backward compability. 

That is basically impossible. We can keep a compatible command-line
interface, but the ABI can't be kept compatible. The interface itself
it quite simple, but we also need new ruleset evaluation functions,
new loop detection and probably a few other things.