On 2020-04-20 3:42 p.m., m...@adrianschmutzler.de wrote:
Hi all,
recently, ramips/mt7621 has switched to DSA and mvebu [1] and kirkwood [2] are
waiting for it.
On ramips, port names have mostly been chosen to be lanX (lan1, lan2, ...) and
wan.
On other targets using DT files from kernel, there doesn't seem to be a particular rule. Sometimes
the same pattern is used, sometimes "wan" is replaced by "internet" and for
kirkwood, we had two cases where ethernetX was used for lan ports.
Being a pedantic person, this bothers me. Despite, having the conversion on
several targets now seems to be a good chance to agree on a guideline for this
_before_ it is done differently everywhere across OpenWrt.
Currently, I see the following options:
1. Stick to what the kernel does:
Where the kernel defines names, just use them. Add them to 02_network and have
them exposed to the user.
For "our" targets, we will still have to decide. For other targets, just do
what similar devices have done (though kernel might be inconsistent there even for
related devices).
Adjusting them in kernel seems no option, as we've learned from Linksys
nicknames discussion that labels might be considered ABI.
This will be the cheapest way.
2. Use a common scheme
We may define a common scheme, e.g. the lanX and wan names as used on
ramips/mt7621 after bump to 5.4.
That will require to change corresponding DTS files with other names from
kernel and keep those patches forever. They will be trivial to make and very
easy to rebase/refresh, but we have to keep them.
On the plus side: User experience (for most users) will be improved. While
there still is inconsistency between swconfig and DSA, at least DSA won't have
subspecies then. So, the average user could expect a lan port to be called
lan1, lan2, ... etc. instead of having to look it up. Our user-space config
files (board.d) would be easier/more unified.
Of course, some advanced users switching between distros (where this is
possible) would have changing interface names, but a lot else will change for
them as well.
3. Care for vendor names
In particular cases, e.g. for EdgeRouter X [3], we are currently using labels
following the vendor scheme (eth0 to eth4 instead of lan0 to lan4).
This could represent an additional option, both in case of using scheme 2 or
for our own targets if we stick to scheme 1.
This would break the "unified user experience" as in scheme 2, but would fulfill
"what the user expects from vendor", like we do it for MAC address, LED behavior etc.
Personally, I have a preference for 2 (and am unsure about 3), as to me the
user experience is the most valuable asset in this context and I do not want to
have to stick to some name the kernel have agreed on in a single case 10 years
ago (exaggerating here, no offense ...).
While I don't have any strong opinion, I believe that from a 'product'
standpoint, it may be best to just match the actual port name when
available. The main drawback to this would be when we have the same
image for devices that have different labels though I am not sure how
often that actually happens.
From a management perspective, having names that make it obvious that
you are dealing with DSA ports (swXpY) would likely make most sense.
Edgerouter X is a good example of this. Calling ports ethX leads to
confusion because it makes the port sound like an ethernet device when
in reality it is a switch port.
I think trying to standardize to wan/lanX names could lead to
unnecessary confusion and pain in the long run.
Please share your thoughts.
Best
Adrian
[1] https://github.com/openwrt/openwrt/pull/2935
[2] https://github.com/openwrt/openwrt/pull/2944
[3]
https://github.com/openwrt/openwrt/commit/5acd1ed0be0d78847cd7d9d5599526f59babaf4d
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
