[OpenWrt-Devel] Port labels for DSA targets/devices

[mail at adrianschmutzler.de]

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 ...).

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20200420/139fe38c/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel