On Friday 2008-08-15 20:38, Changli Gao wrote:
>On Sat, Aug 16, 2008 at 6:44 AM, Jozsef Kadlecsik
><kadlec@xxxxxxxxxxxxxxxxx> wrote:
>> On Fri, 15 Aug 2008, Jan Engelhardt wrote:
>>
>It sounds a good idae. But in order to avoid clashing, we'd better
>change all the options for all matches in this way:
>
>match: foo
>match-options: --foo-bar
>
>I don't mean that some maches share the same options is encouraged,
>but I don't think it lose readable, as I think most of people will
>think the long options after a "-m" option until another match appears
>with the leading "-m" are all for this corresponding match. Global
>option naming space allow commands like this:
>
>iptables ... -m a --a-option-1 -m b --b-option-1 --a-option-2
>
>Oh, I think it make the command unreadable, and we should not allow it happen.
As I see it, -m enables a new set of options and brings them in top
priority, possibly overriding older ones. And because matches don't
get printed in whacky option order when running iptables-save or
similar, I see nothing wrong with keeping it that way and go on
sometimes having same --names for different -m. It's kinda redundant
to give --set-mark with -j MARK, because eh well obviously it will
set the mark in some way, it could have just been -j MARK --mark 17.
>I encountered this issue when I debugging a match. Its parse function
>is like this:
>
>parse(...)
>{
> if (*flags)
> error...;
> switch (c) {
> case 'a':
> ....
> break;
> default:
> return 0;
> }
> *flags = 1;
>
> return 1;
>}
>
>it will fail if there is another kinds of match after it, as all the
>options not belong to it are parsed to its parse function. I think it
>is the reason why default branch in switch exists. I make things a
>little different from my original thought.
Why should it fail?
Once you gave -m secondmatch, you OBVIOUSLY want options
from the second one, and rarely from the first.
>When writting this, I get another idea to solve this. Before calling
>the parse function, we should check if c is in the option range with
>one line code:
>
>c > m->option_offset && c < m->option_offset + OPTION_OFFSET
Just how the hell is that supposed to work.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
