On Fri, Sep 4, 2020 at 3:20 AM Fernando Fernandez Mancera ferferna@redhat.com wrote:
Why would that be that bad? In this case the word will only be used on internal code and nmstate API. If in the future there is an agreement on the kernel we are open to adopt it. I hope this is not a problem for the kernel.
I was under the impression we were trying to select terms that could easily be used everywhere. Part of me would like to use port in the bonding driver, which would actually mirror the team driver, but doing so would cause even more renaming churn in the bonding driver, due to it already being used in other contexts:
$ git grep -c port drivers/net/bonding/ drivers/net/bonding/bond_3ad.c:771 drivers/net/bonding/bond_alb.c:2 drivers/net/bonding/bond_main.c:45 drivers/net/bonding/bond_netlink.c:9 drivers/net/bonding/bond_options.c:10 drivers/net/bonding/bond_procfs.c:28 drivers/net/bonding/bond_sysfs.c:11 drivers/net/bonding/bond_sysfs_slave.c:15
It could be done, but... it would be very messy. Another combo I like, but hadn't looked into until now: master -> aggregate and slave -> link, since bonding is explicitly described as being a link aggregation driver. There's use of 'link' in the bonding driver already, but it looks fairly simple to adjust (it's used for link state tracking, up/down/etc)...
On Thu, Sep 3, 2020 at 10:01 PM Jarod Wilson jarod@redhat.com wrote:
On Thu, Sep 3, 2020 at 3:51 PM Fernando Fernandez Mancera ferferna@redhat.com wrote:
Hello everyone,
After discussing the inclusive language topic with the core Nmstate team and listening to the NetworkManager team suggestions, we have decided to go to use of the word "ports" for the API in replacement of "slaves" as this is the only occurrence that needs to be changed in the public API. This decision has been taken because VLAN is already using "parent/child" and it could be a port of a bridge so it will cause confusion.
The idea is to use "port" because team and linux bridge interfaces are using it currently, too. The change will only be needed on bond and ovs-bridge interfaces. On the API there is no mention of "master". Therefore, no change is needed on that. On the internal code, “master” will be replaced with “controller”.
The plan action is:
- Add the new words to the API and mark as deprecated the old ones.
That means the users will be able to use the old one but they are going to get a warning. 2. Replace the words in the internal code. 3. In the future, we are going to remove the old words. There is not a date, yet, but please move to the new terms now.. 4. If there is any agreement/standard in the future, we are going to consider adopting the proposed new terms.
Thank you for the hard work and your interest in discussing this. We really appreciate all your different perspectives and we can continue this discussion on the kernel or IEEE/IETF.
Well. That was an unfortunate decision from a bonding driver point of view. As I thought I'd previously mentioned, 'port' is already used quite extensively in the bonding driver's 802.3ad/lacp code.
-- Jarod Wilson jarod@redhat.com