Re: About matching (also was: Multiple Targets)

[Martijn Lievaart <m@rtij.nl>]

Jonas Berlin wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Quoting Martijn Lievaart on 2005-04-13 10:09 UTC:
>  
>
>>The more I think about it, the more I like it. This in effect gives
>>multiple targets. Now someone is bound to come up with the idea that it
>>should also be possible to write
>>
>>iptables -A SOMECHAIN -m this -m that -j ACTION1 -j ACTION2 -j RETURN
>>
>>as syntactic sugar. This makes a lot of sense, but is not needed. Let
>>some front-end tool compile the rules to the --previous form, don't
>>burden netfilter with this, unless it can be implemented very easily,
>>which I don't think it can. The semantics are to murky.
>>    
>>
>
>Did you see the mail from me on Mon, 11 Apr 2005 09:47:41 +0000 ? It's
>the first email with the subject
>   "Re: About matching (also was: Multiple Targets)
>
>I wrote some thoughts on how multiple targets could be implemented.
>
>Regarding the rule byte & packet counters, I guess they would be updated
>regardless of how the actions turn out.. (I guess that's how it works
>now too)
>  
>

:-) So back full circle :-) I read it, but lost track of it in the chain.

I'm still not convinced we need this, but it /could/ be implemented 
using an (then internal) --previous match.

IF (and I'm still not convinced it's a good idea) this is implemented, 
there are three ways to do it as I see it now:
1) Either implement --previous wholy in the kernel and make the multiple 
targets part of the kernel interface.
2) Or make this syntactic sugar in the iptables binary.
3) Or don't use any form of --previous and implement it differently in 
the kernel.

1) and 3) are really equivalent from a users point of view, also from 
the viewpoint of binary compatibility. It's just an implementation 
detail. OTOH 2) can be implemented sanely in all the binaries (iptables, 
-save and -restore) but will make the kernel API divert semantically 
from the commandline API. I'm not sure we want that. I still would 
advocate to make an explicit --previous match with semantics as outlined 
in my previous mail. It implements the functionality we want (as Patrick 
points out in another mail you would need an -j RETURN --up 2 to 
implement the same, it can also be done with a GOTO).

M4