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

[Jo-Philipp Wich]

Hi Luiz,

I mostly agree with your proposal (though I'd call "device_for" simply
"bridge" instead but that's details).

I don't think everything can be simply switched in one go but I do think your
proposal could be broken down into the following measures.

The simple things:

 - Rename "config wifi-device" to "config radio", keep supporting the old
   name for backwards compatibility

 - For network.device sections, make "option name" optional and default it
   to the section name, ignore section if it is anonymous and no option name
   is set

The harder things:

 - Untangle the meaning of "option ifname" - for some protocols it specifies
   the existing device to use, for some protocols, e.g. tunnel ones, it
   specifies the name of the device to create. Ideally we should switch to
   "option device"  instead and introduce an "option name" for those cases
   where the resulting device name is controllable. This would also clear up
   some quirks with protocol types that both use a physical link and create a
   tunnel interface on top like PPPoE. One could then use "option device eth0"
   and "option name pppoe-wan" to specify both the L2 device to use and the
   name of the L3 device to create.

 - Support "@" style notation for "option device" to resolve netdev names once
   the above untangling is done

 - Handling name clashes and device name limitations. Given tunnel devices
   with arbitrary names and - since the introduction of DSA - existing netdevs
   with generic names like "wan", "lan1" etc. clashes between configured
   bridge or tunnel devices and existing netdevs become likely. What should
   happen if a bridge with name "wan" is declared and a "wan" DSA port device
   already exists on the system? What should happen if a chosen name exceeds
   the 15 byte ifname limit?

 - Transform "config wifi-iface" in the wireless config into "config device"
   in the network config and handle it like yet another device type which
   happens to understand the various logical wifi network properties like
   SSID, encryption etc. Problem here: a logical wifi network does not really
   represent a 1:1 relationship to a netdev in all cases, an AP/VLAN interface
   for example will create a new vlan-subdevice for each associated station,
   so one wifi network can result in N+1 wifi netdevs. The only sensible
   use case for such uci "devices" would be associating them with a bridge
   or to leave them alone in case something outside of netifd's realm is
   somehow dealing with the existing vlan netdevs. What likely would not work
   is associating them with a "config interface" that specifies "proto static"
   since multiple netdev would get the same subnets assigned then

Things to consider:

 - In addition to shell based protocol handlers, implement a similar machinery
   for shell based device type handlers to allow to quickly bootstrap uci
   support for new device types (think things like veth, vxlan etc. - I know
   that they have been implemented in C already for netifd, but just serving
   as an example)

 - When actually moving "config wifi-iface" as "config device" to the network
   config, it might make sense to move "config wifi-device" as "config radio"
   to the network config as well, entirely eliminating /etc/config/wireless

 - If we find some way to deal with name clashes (what about MS DOS style
   wan~1 :P), consider eliminating the concept of protocol prefixes like
   "pppoe-", "3g-" etc.


I probably missed many details, but I think we really should consider tidying
up the network configuration.

Regards,
Jo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20200724/faa3caee/attachment.sig>