[Dnsmasq-discuss] IP address based on switch port number (option 82)
richardvoigt at gmail.com
richardvoigt at gmail.com
Thu Feb 18 04:24:57 GMT 2010
On Wed, Feb 17, 2010 at 3:05 PM, Simon Kelley <simon at thekelleys.org.uk> wrote:
> richardvoigt at gmail.com wrote:
>
>> Actually, I think you can avoid that without loss of generality.
>>
>> By DeMorgan's theorem, the AND and NOT operations currently available
>> are sufficient to define any expression. You just need a way to do
>> grouping, which a syntax for setting one tag conditionally based on
>> another tag would do.
>>
>> Remember that the example given doesn't need a complement applied, you
>> can negate it in the match later.
>>
>> Since "if" is a very well understood concept, I'd propose
>>
>> tag-if switch1,port1 newtag
>>
>> Where newtag gets set if all listed tags are matched. Using multiple
>> tag-if lines lets you effectively OR things together (this yields
>> sum-of-products capability). Allow a user to unset a tag with
>>
>> tag-if #switch1,port15 #newtag
>>
>> for even more flexibility, but now all tag-if commands need to be
>> processed in order.
>>
>
> Genius!
>
> That's perfect. I think the second form might not be sensible, since the
> order of lines in the configuration file(s) is not significant anywhere
> else.
>
> The simplest scheme would ban tags defined in tag-if declarations from
> use in other tag-if declarations. If that wasn't done, there would be a
> need for multiple iterations to find all the tag values, and the
> possibility of unresolvable data-loops exemplified by
>
> tag-if black, white
> tag-if white, black
as long as you're not going to prohibit
tag-if set:hipower tag:uv
tag-if set:hipower tag:violet
tag-if set:hipower tag:indigo
tag-if set:hipower tag:blue
tag-if set:visible tag:violet
tag-if set:visible tag:indigo
tag-if set:visible tag:blue
tag-if set:visible tag:green
tag-if set:visible tag:yellow
tag-if set:visible tag:orange
tag-if set:visible tag:red
which means
hipower := blue + indigo + violet + uv;
visible := violet + indigo + blue + green + yellow + orange + red;
and then you could e.g. assign a dhcp pool to tag:visible while
assigning a default gateway to tag:hipower (and a different one to
tag:!hipower), and then assign a different bootp image for each color
individually.
Actually, instead of prohibiting use of tags set by tag-if for further
tag-if, I think it's more reasonable to execute the lines in order and
generate a warning if there's any attempted backpropagation. I mean,
build a cumulative list of tags which appear on the condition side
(tag:xyz) of tag-if lines. If any tag-if would set:xyz when xyz is in
the list of matched tags, warn. But allow this:
tag-if set:F tag:A,tag:B
tag-if set:F tag:C
tag-if set:G tag:F,tag:D
which yields
G := ((A*B) + C) * D;
without recursive parsing.
But then warn if a later line contained:
tag-if set:D (any condition here)
because D is already tested in a tag-if
Of course this isn't really necessary, we can expand to
sum-of-products as follows:
G := (A*B*D) + (C*D);
and get the same result via non-iterative conditional tagging:
tag-if set:G tag:A,tag:B,tag:D
tag-if set:G tag:C,tag:D
>
> I'd modify the syntax to match the changes in 2.53 where testing the
> value of a tag is always done with tag:<tagname> and setting a tag is
> always done with set:<tagname>, and ! is used for NOT. So we end up with
>
> tag-if set:newtag, tag:!switch1, tag:port15
>
> I like. Back soon with a test implementation.
>
>
> Simon.
More information about the Dnsmasq-discuss
mailing list