Hi, > [...] > The same feeling is still with this DSA proposal. The syntax "lan2.t > lan2 lan3 lan5" is unstructured and it does not help too.
What is unstructured about it? The fact that it is not a uci list? That can be easily changed. > The use of "switch0" for cpu interface is good and I think it should > even be used for swconfig (simply rename eth0 to switch0 by default > and it will improve usability). I agree but I don't think it'll ever materialize for swconfig. > Trying to reuse the current swconfig syntax might be a curse that will > haunt us. We could have simply 2 sections: bridge (L2) and interface > (L3). My proposal: > > config bridge br-lan <- the real bridge device name This is invalid uci syntax, dashes are not allowed. It also duplicates "config device" with "option type bridge". > option type "auto" # use the best way to merge every ports What possible ways would there be? > # swconfig > [...] Skipped because I don't think there will be new syntax for swconfig anymore. > # DSA > list port lan1 # lan1, no vlan filtering (trunk mode) > list port lan2.1 # lan2 port, vlan 1, untagged > list port lan3.1t # lan3 port, vlan 1, tagged > list port lan3.2t # lan3 port, vlan 2, tagged All of that except vlan/untagged are already possible using: config interface foo option type bridge list ifname lan1 list ifname lan2.1 list ifname lan3.1 list ifname lan3.2 option proto ... or alternatively using: config device option type bridge option name blah0 list ifname lan1 list ifname lan2.1 list ifname lan3.1 list ifname lan3.2 > [...] > > My proposal might have tons of uncovered cases (PPPoE, vlan, tunnel) > but it looks easier than current swconfig and dsa proposed > configuration. It might be a matter of taste but personally I don't see what is easier about it. The main change seems to be that instead by VLAN ID, your proposal groups the port memberships by bridge. So instead having a vlan section that attaches ports to a bridge, you declare a bridge containing ports with their respective VLAN IDs. > The main points are to split L2 and L3 confs, split port list into > individual options and let the system decide the best way to implement > the proposed setup. Point 1 is already doable, point 2 can be easily added (in fact changing "option ports 'lan1 lan2 lan3'" to "list ports lan1; list ports lan2; list ports lan3" is possible without changing any code). I disagree with point 3. Having a network config that automagically translates into different things on different boards makes debugging potential issues very hard. The uci network config is too low level for that imho. Regards, Jo
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
