On Wed, Jan 15, 2014 at 04:58:49PM +0100, Pablo Neira Ayuso wrote:
> On Wed, Jan 15, 2014 at 10:29:43AM +0100, Pablo Neira Ayuso wrote:
> > On Tue, Jan 14, 2014 at 03:49:00PM +0000, Patrick McHardy wrote:
> > > Well, I think the easiest approach would be to add some code to
> > > expr_evaluate_relational() for OP_EQ for convert the LHS of a
> > > relational meta expression to LHS & RHS:
> > >
> > > relational (==)
> > > / \
> > > meta oifname string
> > >
> > > =>
> > >
> > > relational (==)
> > > / \
> > > binop (&) string
> > > / \
> > > meta oifname string
> > >
> > > The attached patch uses '*' as a trigger (and obviously won't work
> > > because the '*' is also used in the mask, but you get the idea.
> > > netlink_delinarize adjustments are missing, but it should be pretty
> > > trivial to add the corresponding code to postprocessing of relational
> > > expressions.
> >
> > Oh yes, with that wildcard trick the thing is simplified. There was
> > some discuss on the use of '+' that seems to be possible to be used in
> > a device name. I guess '*' is safe as udev is using it in their rules.
>
> It seems we need to include the '*' into the string rule in flex for
> this. We already have a single '*' that is used in the parser for
> prefixes, I think that may lead to ambiguity problems.
We of course could use something different, but I think it should be fine.
The '*' for prefixes can be reasonable expected to follow some whitespace,
while in this case it would always be the final character of a string.
This *seems* to work in some very limited testing.
diff --git a/src/scanner.l b/src/scanner.l
index 6ff8846..abc46e1 100644
--- a/src/scanner.l
+++ b/src/scanner.l
@@ -439,6 +439,11 @@ addrstring ({macaddr}|{ip4addr}|{ip6addr})
return STRING;
}
+{string}\* {
+ yylval->string = xstrdup(yytext);
+ return STRING;
+ }
+
\\{newline} {
reset_pos(yyget_extra(yyscanner), yylloc);
}
--
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
