Hi,
Am Fr., 4. Sept. 2020 um 15:47 Uhr schrieb Jarod Wilson <jarod(a)redhat.com>:
On Fri, Sep 4, 2020 at 3:20 AM Fernando Fernandez Mancera
<ferferna(a)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
Yes, that would be the holy grail. This is why we are still open for
further changes in the future if better terms become widely accepted.
Also, for NetworkManager it is more complicated, so would still
welcome an agreement that would help to improve NetworkManager, too.
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,
Just wondering, would it be possible to use port on the public part,
which might be just the output of /proc/net/bonding/$interface - so
Primary Port:
Currently Active Port:
Port Interface:
Port queue ID:
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)...
sounds like good terms, too. Just wondering, who needs to be convinced
on the kernel side to move this forward?
Thanks
Till
> On Thu, Sep 3, 2020 at 10:01 PM Jarod Wilson <jarod(a)redhat.com> wrote:
> >
> > On Thu, Sep 3, 2020 at 3:51 PM Fernando Fernandez Mancera
> > <ferferna(a)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:
> > > 1. 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(a)redhat.com
> >
>
--
Jarod Wilson
jarod(a)redhat.com
--
Till Maas
He/His/Him
Associate Manager, Software Engineering
NetworkManager, Nmstate, Ansible RHEL Networking System Role
Red Hat GmbH,
https://de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill