[RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

[Josh Bendavid]

Ok thanks.
I think my main point was not that this belongs in interface per-se,
but that it makes sense for the configuration of vlan tagging to apply
to bridges in general (and to have as little as possible special
handling of dsa in uci, since the logic is that it should be possible
to configure it exactly as a generic bridge)

On Tue, 14 Jul 2020 at 19:05, Jo-Philipp Wich <jo at mein.io> wrote:
>
> Hi,
>
> > [...]
> > Isn't it conceptually more correct in this case for the vlan filtering
> > to be configured as part of the "interface" in uci?
> > Ie I configure an interface of type "bridge" which bridges the switch
> > ports, then the vlan filtering is a configuration property of this
> > interface (just like enabling igmp_snooping on a bridge interface)
>
> the "config interface" section type already is quite overloaded with different
> layer2 and layer3 configuration semantics which leads to confusion and quirks,
> as can be seen e.g. with "option mtu" on top of PPPoE interfaces or "option
> mac" on bridges.
>
> I agree that this setting could conceptually make sense in a "config device"
> section of type bridge, but with the VLAN filter settings being
> multi-dimensional it does not fit very well into simple uci option values
> without defining yet another micro format to declare VLAN / port memberships.
>
> The proposed dsaconfig approach has been selected due to its similarity with
> swconfig, it is easier to understand for people already used to swconfig and
> even allows for some automatic configuration conversion to some extent.
>
> I also do see it as a complementary higher level kind of configuration. It is
> entirely opt-in and can be supplemented or superseded with per-interface and
> per-device attributes that are implemented in netifd eventually.
>
>
> Regards,
> Jo
>