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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel