[RFC] bonding driver terminology change proposal

[RFC] bonding driver terminology change proposal

[Jarod Wilson]

As part of an effort to help enact social change, Red Hat is
committing to efforts to eliminate any problematic terminology from
any of the software that it ships and supports. Front and center for
me personally in that effort is the bonding driver's use of the terms
master and slave, and to a lesser extent, bond and bonding, due to
bondage being another term for slavery. Most people in computer
science understand these terms aren't intended to be offensive or
oppressive, and have well understood meanings in computing, but
nonetheless, they still present an open wound, and a barrier for
participation and inclusion to some.

To start out with, I'd like to attempt to eliminate as much of the use
of master and slave in the bonding driver as possible. For the most
part, I think this can be done without breaking UAPI, but may require
changes to anything accessing bond info via proc or sysfs.

My initial thought was to rename master to aggregator and slaves to
ports, but... that gets really messy with the existing 802.3ad bonding
code using both extensively already. I've given thought to a number of
other possible combinations, but the one that I'm liking the most is
master -> bundle and slave -> cable, for a number of reasons. I'd
considered cable and wire, as a cable is a grouping of individual
wires, but we're grouping together cables, really -- each bonded
ethernet interface has a cable connected, so a bundle of cables makes
sense visually and figuratively. Additionally, it's a swap made easier
in the codebase by master and bundle and slave and cable having the
same number of characters, respectively. Granted though, "bundle"
doesn't suggest "runs the show" the way "master" or something like
maybe "director" or "parent" does, but those lack the visual aspect
present with a bundle of cables. Using parent/child could work too
though, it's perhaps closer to the master/slave terminology currently
in use as far as literal meaning.

So... Thoughts?

For reference, a work-in-progress adaptation from master/slave to
bundle/cable has a diffstat that is currently summarized as:

 37 files changed, 2607 insertions(+), 2571 deletions(-)

-- 
Jarod Wilson
jarod@redhat.com

Re: [RFC] bonding driver terminology change proposal

[Eric Dumazet]

On 7/13/20 11:51 AM, Jarod Wilson wrote:
> As part of an effort to help enact social change, Red Hat is
> committing to efforts to eliminate any problematic terminology from
> any of the software that it ships and supports. Front and center for
> me personally in that effort is the bonding driver's use of the terms
> master and slave, and to a lesser extent, bond and bonding, due to
> bondage being another term for slavery. Most people in computer
> science understand these terms aren't intended to be offensive or
> oppressive, and have well understood meanings in computing, but
> nonetheless, they still present an open wound, and a barrier for
> participation and inclusion to some.
> 
> To start out with, I'd like to attempt to eliminate as much of the use
> of master and slave in the bonding driver as possible. For the most
> part, I think this can be done without breaking UAPI, but may require
> changes to anything accessing bond info via proc or sysfs.
> 
> My initial thought was to rename master to aggregator and slaves to
> ports, but... that gets really messy with the existing 802.3ad bonding
> code using both extensively already. I've given thought to a number of
> other possible combinations, but the one that I'm liking the most is
> master -> bundle and slave -> cable, for a number of reasons. I'd
> considered cable and wire, as a cable is a grouping of individual
> wires, but we're grouping together cables, really -- each bonded
> ethernet interface has a cable connected, so a bundle of cables makes
> sense visually and figuratively. Additionally, it's a swap made easier
> in the codebase by master and bundle and slave and cable having the
> same number of characters, respectively. Granted though, "bundle"
> doesn't suggest "runs the show" the way "master" or something like
> maybe "director" or "parent" does, but those lack the visual aspect
> present with a bundle of cables. Using parent/child could work too
> though, it's perhaps closer to the master/slave terminology currently
> in use as far as literal meaning.
> 
> So... Thoughts?
> 

So you considered : aggregator/ports, bundle/cable.

I thought about cord/strand, since this is less likely to be used already in networking land
(like worker, thread, fiber, or wire ...)

Although a cord with two strands is probably not very common :/

Re: [RFC] bonding driver terminology change proposal

[Michal Kubecek]

On Mon, Jul 13, 2020 at 02:51:39PM -0400, Jarod Wilson wrote:
> To start out with, I'd like to attempt to eliminate as much of the use
> of master and slave in the bonding driver as possible. For the most
> part, I think this can be done without breaking UAPI, but may require
> changes to anything accessing bond info via proc or sysfs.

Could we, please, avoid breaking existing userspace tools and scripts?
Massive code churn is one thing and we could certainly bite the bullet
and live with it (even if I'm still not convinced it would be as great
idea as some present it) but trading theoretical offense for real and
palpable harm to existing users is something completely different.

Or is "don't break userspace" no longer the "first commandment" of linux
kernel development?

Michal Kubecek

Re: [RFC] bonding driver terminology change proposal

[Stephen Hemminger]

On Tue, 14 Jul 2020 00:00:16 +0200
Michal Kubecek <mkubecek@suse.cz> wrote:

> On Mon, Jul 13, 2020 at 02:51:39PM -0400, Jarod Wilson wrote:
> > To start out with, I'd like to attempt to eliminate as much of the use
> > of master and slave in the bonding driver as possible. For the most
> > part, I think this can be done without breaking UAPI, but may require
> > changes to anything accessing bond info via proc or sysfs.  
> 
> Could we, please, avoid breaking existing userspace tools and scripts?
> Massive code churn is one thing and we could certainly bite the bullet
> and live with it (even if I'm still not convinced it would be as great
> idea as some present it) but trading theoretical offense for real and
> palpable harm to existing users is something completely different.
> 
> Or is "don't break userspace" no longer the "first commandment" of linux
> kernel development?
> 
> Michal Kubecek

Please consider using same wording as current standard for link aggregration.
Current version is 802.1AX and it uses the terms:
  Multiplexer /  Aggregator

There are no uses of master or slave in 802.1Ax standard.

As far as userspace, maybe keep the old API's but provide deprecation nags.
And don't document the old API values.

Re: [RFC] bonding driver terminology change proposal

[Michal Kubecek]

On Mon, Jul 13, 2020 at 03:41:18PM -0700, Stephen Hemminger wrote:
> On Tue, 14 Jul 2020 00:00:16 +0200
> Michal Kubecek <mkubecek@suse.cz> wrote:
> 
> > On Mon, Jul 13, 2020 at 02:51:39PM -0400, Jarod Wilson wrote:
> > > To start out with, I'd like to attempt to eliminate as much of the use
> > > of master and slave in the bonding driver as possible. For the most
> > > part, I think this can be done without breaking UAPI, but may require
> > > changes to anything accessing bond info via proc or sysfs.  
> > 
> > Could we, please, avoid breaking existing userspace tools and scripts?
> > Massive code churn is one thing and we could certainly bite the bullet
> > and live with it (even if I'm still not convinced it would be as great
> > idea as some present it) but trading theoretical offense for real and
> > palpable harm to existing users is something completely different.
> > 
> > Or is "don't break userspace" no longer the "first commandment" of linux
> > kernel development?
> > 
> > Michal Kubecek
> 
> Please consider using same wording as current standard for link aggregration.
> Current version is 802.1AX and it uses the terms:
>   Multiplexer /  Aggregator

But both of these are replacements for "master", right?

> As far as userspace, maybe keep the old API's but provide deprecation nags.
> And don't document the old API values.

I'm not a fan of nagging users. And even less of a fan of undocumented
keyword and value aliases.

Michal

Re: [RFC] bonding driver terminology change proposal

[Andrew Lunn]

Hi Jarod

Do you have this change scripted? Could you apply the script to v5.4
and then cherry-pick the 8 bonding fixes that exist in v5.4.51. How
many result in conflicts?

Could you do the same with v4.19...v4.19.132, which has 20 fixes.

This will give us an idea of the maintenance overhead such a change is
going to cause, and how good git is at figuring out this sort of
thing.

	Andrew

Re: [RFC] bonding driver terminology change proposal

[David Miller]

From: Jarod Wilson <jarod@redhat.com>
Date: Mon, 13 Jul 2020 14:51:39 -0400

> To start out with, I'd like to attempt to eliminate as much of the use
> of master and slave in the bonding driver as possible. For the most
> part, I think this can be done without breaking UAPI, but may require
> changes to anything accessing bond info via proc or sysfs.

You can change what you want internally to the driver in order to meet
this objective, but I am positively sure that external facing UAPI has
to be retained.

Re: [RFC] bonding driver terminology change proposal

[Jay Vosburgh]

Stephen Hemminger <stephen@networkplumber.org> wrote:

>On Tue, 14 Jul 2020 00:00:16 +0200
>Michal Kubecek <mkubecek@suse.cz> wrote:
>
>> On Mon, Jul 13, 2020 at 02:51:39PM -0400, Jarod Wilson wrote:
>> > To start out with, I'd like to attempt to eliminate as much of the use
>> > of master and slave in the bonding driver as possible. For the most
>> > part, I think this can be done without breaking UAPI, but may require
>> > changes to anything accessing bond info via proc or sysfs.  
>> 
>> Could we, please, avoid breaking existing userspace tools and scripts?
>> Massive code churn is one thing and we could certainly bite the bullet
>> and live with it (even if I'm still not convinced it would be as great
>> idea as some present it) but trading theoretical offense for real and
>> palpable harm to existing users is something completely different.
>> 
>> Or is "don't break userspace" no longer the "first commandment" of linux
>> kernel development?
>> 
>> Michal Kubecek
>
>Please consider using same wording as current standard for link aggregration.
>Current version is 802.1AX and it uses the terms:
>  Multiplexer /  Aggregator

	Well, 802.1AX only defines LACP, and the bonding driver does
more than just LACP.  Also, Multiplexer, in 802.1AX, is a function of
various components, e.g., each Aggregator has a Multiplexer, as do other
components.

	As "channel bonding" is a long-established term of art, I don't
see an issue with something like "bond" and "port," which parallels the
bridge / port terminology.

[...]
>As far as userspace, maybe keep the old API's but provide deprecation nags.
>And don't document the old API values.

	Unless the community stance on not breaking user space has
changed, the extant APIs must be maintained.  In the context of bonding,
this would include "ip link" command line arguments, sysfs and procsfs
interfaces, as well as netlink attribute names.  There are also exported
kernel APIs that bonding utilizes, netdev_master_upper_dev_link, et al.

	Additionally, just to be absolutely clear, is the proposal here
intending to undertake a rather significant search and replace of the
text strings "master" and "slave" within the bonding driver source?
This in addition to whatever API changes end up being done.  If so, then
I would also like to know the answer to Andrew's question regarding
patch conflicts in order to gauge the future maintenance cost.

	-J

---
	-Jay Vosburgh, jay.vosburgh@canonical.com

Re: [RFC] bonding driver terminology change proposal

[David Miller]

From: Michal Kubecek <mkubecek@suse.cz>
Date: Tue, 14 Jul 2020 00:00:16 +0200

> Could we, please, avoid breaking existing userspace tools and scripts?

I will not let UAPI breakage, don't worry.

Re: [RFC] bonding driver terminology change proposal

[Jarod Wilson]

On Mon, Jul 13, 2020 at 5:36 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> On 7/13/20 11:51 AM, Jarod Wilson wrote:
> > As part of an effort to help enact social change, Red Hat is
> > committing to efforts to eliminate any problematic terminology from
> > any of the software that it ships and supports. Front and center for
> > me personally in that effort is the bonding driver's use of the terms
> > master and slave, and to a lesser extent, bond and bonding, due to
> > bondage being another term for slavery. Most people in computer
> > science understand these terms aren't intended to be offensive or
> > oppressive, and have well understood meanings in computing, but
> > nonetheless, they still present an open wound, and a barrier for
> > participation and inclusion to some.
> >
> > To start out with, I'd like to attempt to eliminate as much of the use
> > of master and slave in the bonding driver as possible. For the most
> > part, I think this can be done without breaking UAPI, but may require
> > changes to anything accessing bond info via proc or sysfs.
> >
> > My initial thought was to rename master to aggregator and slaves to
> > ports, but... that gets really messy with the existing 802.3ad bonding
> > code using both extensively already. I've given thought to a number of
> > other possible combinations, but the one that I'm liking the most is
> > master -> bundle and slave -> cable, for a number of reasons. I'd
> > considered cable and wire, as a cable is a grouping of individual
> > wires, but we're grouping together cables, really -- each bonded
> > ethernet interface has a cable connected, so a bundle of cables makes
> > sense visually and figuratively. Additionally, it's a swap made easier
> > in the codebase by master and bundle and slave and cable having the
> > same number of characters, respectively. Granted though, "bundle"
> > doesn't suggest "runs the show" the way "master" or something like
> > maybe "director" or "parent" does, but those lack the visual aspect
> > present with a bundle of cables. Using parent/child could work too
> > though, it's perhaps closer to the master/slave terminology currently
> > in use as far as literal meaning.
> >
> > So... Thoughts?
> >
>
> So you considered : aggregator/ports, bundle/cable.
>
> I thought about cord/strand, since this is less likely to be used already in networking land
> (like worker, thread, fiber, or wire ...)
>
> Although a cord with two strands is probably not very common :/

I'd also thought about cable and wire, since there are multiple
physical wires inside an ethernet cable, but you typically connect one
cable per port, so a bundle of cables seemed to make more sense. :) I
also had a few other ideas I played with, including a bundle of pipes
and a pipework of pipes (which is apparently a thing, but not very
common either, outside of maybe plumbers?).

-- 
Jarod Wilson
jarod@redhat.com

Re: [RFC] bonding driver terminology change proposal

[Jarod Wilson]

On Mon, Jul 13, 2020 at 6:00 PM Michal Kubecek <mkubecek@suse.cz> wrote:
>
> On Mon, Jul 13, 2020 at 02:51:39PM -0400, Jarod Wilson wrote:
> > To start out with, I'd like to attempt to eliminate as much of the use
> > of master and slave in the bonding driver as possible. For the most
> > part, I think this can be done without breaking UAPI, but may require
> > changes to anything accessing bond info via proc or sysfs.
>
> Could we, please, avoid breaking existing userspace tools and scripts?
> Massive code churn is one thing and we could certainly bite the bullet
> and live with it (even if I'm still not convinced it would be as great
> idea as some present it) but trading theoretical offense for real and
> palpable harm to existing users is something completely different.
>
> Or is "don't break userspace" no longer the "first commandment" of linux
> kernel development?

Definitely looking to minimize breakage here, and it sounds like it'll
be to the point of "none", or this won't fly. I think this may require
having "legacy" aliases for certain interfaces and the like, to both
provide a less problematic interface name as the new default, but
prevent breaking any existing setups.

-- 
Jarod Wilson
jarod@redhat.com

Re: [RFC] bonding driver terminology change proposal

[Jarod Wilson]

On Mon, Jul 13, 2020 at 8:55 PM Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
>
> Stephen Hemminger <stephen@networkplumber.org> wrote:
>
> >On Tue, 14 Jul 2020 00:00:16 +0200
> >Michal Kubecek <mkubecek@suse.cz> wrote:
> >
> >> On Mon, Jul 13, 2020 at 02:51:39PM -0400, Jarod Wilson wrote:
> >> > To start out with, I'd like to attempt to eliminate as much of the use
> >> > of master and slave in the bonding driver as possible. For the most
> >> > part, I think this can be done without breaking UAPI, but may require
> >> > changes to anything accessing bond info via proc or sysfs.
> >>
> >> Could we, please, avoid breaking existing userspace tools and scripts?
> >> Massive code churn is one thing and we could certainly bite the bullet
> >> and live with it (even if I'm still not convinced it would be as great
> >> idea as some present it) but trading theoretical offense for real and
> >> palpable harm to existing users is something completely different.
> >>
> >> Or is "don't break userspace" no longer the "first commandment" of linux
> >> kernel development?
> >>
> >> Michal Kubecek
> >
> >Please consider using same wording as current standard for link aggregration.
> >Current version is 802.1AX and it uses the terms:
> >  Multiplexer /  Aggregator
>
>         Well, 802.1AX only defines LACP, and the bonding driver does
> more than just LACP.  Also, Multiplexer, in 802.1AX, is a function of
> various components, e.g., each Aggregator has a Multiplexer, as do other
> components.
>
>         As "channel bonding" is a long-established term of art, I don't
> see an issue with something like "bond" and "port," which parallels the
> bridge / port terminology.

I did look at aggregator and port as options, but the overlap with the
bonding 802.3ad code would mean first reworking a bunch of that code
to free up those terms for more general bonding use. I think "bonding"
should be okay to keep around as well, and am kind of on the fence
with "master", since master of ceremonies, masters degress, master
keys, etc are all similar enough to what a master device in a bond
represents, and the main objectionable language is primarily "slave".

One option would be to rename "port" to "laggport" or "adport" or
something like that in the 802.3ad code, and then make use of "port"
in place of slave (which mirrors what's done in the team driver).


> [...]
> >As far as userspace, maybe keep the old API's but provide deprecation nags.
> >And don't document the old API values.
>
>         Unless the community stance on not breaking user space has
> changed, the extant APIs must be maintained.  In the context of bonding,
> this would include "ip link" command line arguments, sysfs and procsfs
> interfaces, as well as netlink attribute names.  There are also exported
> kernel APIs that bonding utilizes, netdev_master_upper_dev_link, et al.

To some people, this could be a case that warranted breaking UAPIs. In
an ideal world, that would be nice, but obviously, breaking the world
to get there isn't good either, so I think maintaining them all is
hopefully still understandable.

>         Additionally, just to be absolutely clear, is the proposal here
> intending to undertake a rather significant search and replace of the
> text strings "master" and "slave" within the bonding driver source?
> This in addition to whatever API changes end up being done.  If so, then
> I would also like to know the answer to Andrew's question regarding
> patch conflicts in order to gauge the future maintenance cost.

Correct, this would be full search-and-replace, with minor tweaks here
and there -- bond_enslave -> bond_connect or something like that,
since bond_encable wouldn't make sense, and replacing references to
ifenslave in the code isn't helpful, since ifenslave is still going to
be called ifenslave.

As of yet, no, I don't have this scripted, but I can certainly give
that a go. I'm not terribly familiar with coccinelle, and if that
would be the way to script it, or if a simple bash/perl/whatever
script would suffice.

--
Jarod Wilson
jarod@redhat.com

Re: [RFC] bonding driver terminology change proposal

[Toke Høiland-Jørgensen]

Jarod Wilson <jarod@redhat.com> writes:

> As part of an effort to help enact social change, Red Hat is
> committing to efforts to eliminate any problematic terminology from
> any of the software that it ships and supports. Front and center for
> me personally in that effort is the bonding driver's use of the terms
> master and slave, and to a lesser extent, bond and bonding, due to
> bondage being another term for slavery. Most people in computer
> science understand these terms aren't intended to be offensive or
> oppressive, and have well understood meanings in computing, but
> nonetheless, they still present an open wound, and a barrier for
> participation and inclusion to some.
>
> To start out with, I'd like to attempt to eliminate as much of the use
> of master and slave in the bonding driver as possible. For the most
> part, I think this can be done without breaking UAPI, but may require
> changes to anything accessing bond info via proc or sysfs.
>
> My initial thought was to rename master to aggregator and slaves to
> ports, but... that gets really messy with the existing 802.3ad bonding
> code using both extensively already. I've given thought to a number of
> other possible combinations, but the one that I'm liking the most is
> master -> bundle and slave -> cable, for a number of reasons. I'd
> considered cable and wire, as a cable is a grouping of individual
> wires, but we're grouping together cables, really -- each bonded
> ethernet interface has a cable connected, so a bundle of cables makes
> sense visually and figuratively. Additionally, it's a swap made easier
> in the codebase by master and bundle and slave and cable having the
> same number of characters, respectively. Granted though, "bundle"
> doesn't suggest "runs the show" the way "master" or something like
> maybe "director" or "parent" does, but those lack the visual aspect
> present with a bundle of cables. Using parent/child could work too
> though, it's perhaps closer to the master/slave terminology currently
> in use as far as literal meaning.

I've always thought of it as a "bond device" which has other netdevs as
"components" (as in 'things that are part of'). So maybe
"main"/"component" or something to that effect?

-Toke

Re: [RFC] bonding driver terminology change proposal

[Marcelo Ricardo Leitner]

On Tue, Jul 14, 2020 at 09:17:48PM +0200, Toke Høiland-Jørgensen wrote:
> Jarod Wilson <jarod@redhat.com> writes:
> 
> > As part of an effort to help enact social change, Red Hat is
> > committing to efforts to eliminate any problematic terminology from
> > any of the software that it ships and supports. Front and center for
> > me personally in that effort is the bonding driver's use of the terms
> > master and slave, and to a lesser extent, bond and bonding, due to
> > bondage being another term for slavery. Most people in computer
> > science understand these terms aren't intended to be offensive or
> > oppressive, and have well understood meanings in computing, but
> > nonetheless, they still present an open wound, and a barrier for
> > participation and inclusion to some.
> >
> > To start out with, I'd like to attempt to eliminate as much of the use
> > of master and slave in the bonding driver as possible. For the most
> > part, I think this can be done without breaking UAPI, but may require
> > changes to anything accessing bond info via proc or sysfs.
> >
> > My initial thought was to rename master to aggregator and slaves to
> > ports, but... that gets really messy with the existing 802.3ad bonding
> > code using both extensively already. I've given thought to a number of
> > other possible combinations, but the one that I'm liking the most is
> > master -> bundle and slave -> cable, for a number of reasons. I'd
> > considered cable and wire, as a cable is a grouping of individual
> > wires, but we're grouping together cables, really -- each bonded
> > ethernet interface has a cable connected, so a bundle of cables makes
> > sense visually and figuratively. Additionally, it's a swap made easier
> > in the codebase by master and bundle and slave and cable having the
> > same number of characters, respectively. Granted though, "bundle"
> > doesn't suggest "runs the show" the way "master" or something like
> > maybe "director" or "parent" does, but those lack the visual aspect
> > present with a bundle of cables. Using parent/child could work too
> > though, it's perhaps closer to the master/slave terminology currently
> > in use as far as literal meaning.
> 
> I've always thought of it as a "bond device" which has other netdevs as
> "components" (as in 'things that are part of'). So maybe
> "main"/"component" or something to that effect?

Same here, and it's pretty much like how I see the bridge as well.
"bridge device" and "legs".

  Marcelo

Re: [RFC] bonding driver terminology change proposal

[Jarod Wilson]

On Tue, Jul 14, 2020 at 4:39 PM Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
>
> On Tue, Jul 14, 2020 at 09:17:48PM +0200, Toke Høiland-Jørgensen wrote:
> > Jarod Wilson <jarod@redhat.com> writes:
> >
> > > As part of an effort to help enact social change, Red Hat is
> > > committing to efforts to eliminate any problematic terminology from
> > > any of the software that it ships and supports. Front and center for
> > > me personally in that effort is the bonding driver's use of the terms
> > > master and slave, and to a lesser extent, bond and bonding, due to
> > > bondage being another term for slavery. Most people in computer
> > > science understand these terms aren't intended to be offensive or
> > > oppressive, and have well understood meanings in computing, but
> > > nonetheless, they still present an open wound, and a barrier for
> > > participation and inclusion to some.
> > >
> > > To start out with, I'd like to attempt to eliminate as much of the use
> > > of master and slave in the bonding driver as possible. For the most
> > > part, I think this can be done without breaking UAPI, but may require
> > > changes to anything accessing bond info via proc or sysfs.
> > >
> > > My initial thought was to rename master to aggregator and slaves to
> > > ports, but... that gets really messy with the existing 802.3ad bonding
> > > code using both extensively already. I've given thought to a number of
> > > other possible combinations, but the one that I'm liking the most is
> > > master -> bundle and slave -> cable, for a number of reasons. I'd
> > > considered cable and wire, as a cable is a grouping of individual
> > > wires, but we're grouping together cables, really -- each bonded
> > > ethernet interface has a cable connected, so a bundle of cables makes
> > > sense visually and figuratively. Additionally, it's a swap made easier
> > > in the codebase by master and bundle and slave and cable having the
> > > same number of characters, respectively. Granted though, "bundle"
> > > doesn't suggest "runs the show" the way "master" or something like
> > > maybe "director" or "parent" does, but those lack the visual aspect
> > > present with a bundle of cables. Using parent/child could work too
> > > though, it's perhaps closer to the master/slave terminology currently
> > > in use as far as literal meaning.
> >
> > I've always thought of it as a "bond device" which has other netdevs as
> > "components" (as in 'things that are part of'). So maybe
> > "main"/"component" or something to that effect?
>
> Same here, and it's pretty much like how I see the bridge as well.
> "bridge device" and "legs".

I did toy with the idea of "torso" or "thorax" for the bond aggregate
device and "legs" for the bond components, but at this point, I guess
it's mostly bikeshedding, the bigger issue is "how messy would it
be?". I've scripted most of the changes, but not all of them. Still
working on it... :)

-- 
Jarod Wilson
jarod@redhat.com

Re: [RFC] bonding driver terminology change proposal

[Edward Cree]

Once again, the opinions below are my own and definitely do not
 represent anything my employer would be seen dead in the same
 room as.

On 13/07/2020 23:41, Stephen Hemminger wrote:
> As far as userspace, maybe keep the old API's but provide deprecation nags.
Why would you need to deprecate the old APIs?
If the user echoes 'slave' into some sysfs file (or whatever), that
 indicates that they don't have any problem with using the word.
So there's no reason toever remove that support — its _mere
 existence_ isn't problematic for anyone not actively seeking to be
 offended.
Which I think is more evidence that this change is not motivated by
 practical concerns but by a kind of performative ritual purity.

This is dumb.  I suspect you all, including Jarod, know that this
 is dumb, but you're either going along with it or keeping your
 head down in the hope that it will all blow over and you can go
 back to normal.  Unfortunately, it doesn't work like that; the
 activists who push this stuff are never satisfied; making
 concessions to them results not in peace but in further demands;
 and just as the corporations today are caving to the current
 demands for fear of being singled out by the mob, so they will
 cave again to the next round of demands, and you'll be back in
 the same position, trying to deal with bosses wanting you to
 break uAPI without even a technical reason.
And next time around, the mob will be bolder and the bosses more
 pliant, because by giving in this time we'll have signalled that
 we're weak and easily dominated.  I would advise anyone still in
 doubt of this point to read Kipling's poem "Dane-geld".
And we'll all be left wondering why kernel development is so
 soulless and joyless that no-one, of _any_ colour, aspires to
 become a kernel hacker any more.

It's not too late to stop the crazy, if we all just stop
 pretending it's sane.

-ed

Re: [RFC] bonding driver terminology change proposal

[Jarod Wilson]

On Wed, Jul 15, 2020 at 8:57 AM Edward Cree <ecree@solarflare.com> wrote:
>
> Once again, the opinions below are my own and definitely do not
>  represent anything my employer would be seen dead in the same
>  room as.
>
> On 13/07/2020 23:41, Stephen Hemminger wrote:
> > As far as userspace, maybe keep the old API's but provide deprecation nags.
> Why would you need to deprecate the old APIs?
> If the user echoes 'slave' into some sysfs file (or whatever), that
>  indicates that they don't have any problem with using the word.
> So there's no reason toever remove that support — its _mere
>  existence_ isn't problematic for anyone not actively seeking to be
>  offended.
> Which I think is more evidence that this change is not motivated by
>  practical concerns but by a kind of performative ritual purity.
>
> This is dumb.  I suspect you all, including Jarod, know that this
>  is dumb, but you're either going along with it or keeping your
>  head down in the hope that it will all blow over and you can go
>  back to normal.  Unfortunately, it doesn't work like that; the
>  activists who push this stuff are never satisfied; making
>  concessions to them results not in peace but in further demands;
>  and just as the corporations today are caving to the current
>  demands for fear of being singled out by the mob, so they will
>  cave again to the next round of demands, and you'll be back in
>  the same position, trying to deal with bosses wanting you to
>  break uAPI without even a technical reason.
> And next time around, the mob will be bolder and the bosses more
>  pliant, because by giving in this time we'll have signalled that
>  we're weak and easily dominated.  I would advise anyone still in
>  doubt of this point to read Kipling's poem "Dane-geld".
> And we'll all be left wondering why kernel development is so
>  soulless and joyless that no-one, of _any_ colour, aspires to
>  become a kernel hacker any more.
>
> It's not too late to stop the crazy, if we all just stop
>  pretending it's sane.

No, it isn't a practical code concern motivating this change, it's
actually quite impractical from a code standpoint and has no technical
merit. I understand your position, but having seen many emotional
responses to issues surrounding this, I think it's a worthwhile effort
that many people actually do appreciate. Even if I'm not personally
offended by the terminology, as a white male, I don't think I possess
the life experiences to downplay the negative impact ongoing use of
terms like "slave" might have on people that are actual descendants of
slavery. Embracing and helping move forward social change seems like a
responsible thing to do here, as long as we can do it without breaking
the kernel and UAPI.

-- 
Jarod Wilson
jarod@redhat.com

Re: [RFC] bonding driver terminology change proposal

[Jarod Wilson]

On Mon, Jul 13, 2020 at 8:26 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> Hi Jarod
>
> Do you have this change scripted? Could you apply the script to v5.4
> and then cherry-pick the 8 bonding fixes that exist in v5.4.51. How
> many result in conflicts?
>
> Could you do the same with v4.19...v4.19.132, which has 20 fixes.
>
> This will give us an idea of the maintenance overhead such a change is
> going to cause, and how good git is at figuring out this sort of
> thing.

Okay, I have some fugly bash scripts that use sed to do the majority
of the work here, save some manual bits done to add duplicate
interfaces w/new names and some aliases, and everything is compiling
and functions in a basic smoke test here.

Summary on the 5.4 git cherry-pick conflict resolution after applying
changes: not that good. 7 of the 8 bonding fixes in the 5.4 stable
branch required fixing when straight cherry-picking. Dumping the
patches, running a sed script over them, and then git am'ing them
works pretty well though. I didn't try 4.19 (yet?), I assume it'll
just be more of the same.

-- 
Jarod Wilson
jarod@redhat.com

Re: [RFC] bonding driver terminology change proposal

[Jarod Wilson]

On Mon, Jul 13, 2020 at 9:00 PM David Miller <davem@davemloft.net> wrote:
>
> From: Michal Kubecek <mkubecek@suse.cz>
> Date: Tue, 14 Jul 2020 00:00:16 +0200
>
> > Could we, please, avoid breaking existing userspace tools and scripts?
>
> I will not let UAPI breakage, don't worry.

Seeking some clarification here. Does the output of
/proc/net/bonding/<bond> fall under that umbrella as well? I'm sure
there are people that do parse it for monitoring, and thus I assume
that it does, but want to be certain. I think this is the only
remaining thing I need to address in a local test conversion build.

-- 
Jarod Wilson
jarod@redhat.com

Re: [RFC] bonding driver terminology change proposal

[Andrew Lunn]

On Wed, Jul 15, 2020 at 11:04:16PM -0400, Jarod Wilson wrote:
> On Mon, Jul 13, 2020 at 8:26 PM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > Hi Jarod
> >
> > Do you have this change scripted? Could you apply the script to v5.4
> > and then cherry-pick the 8 bonding fixes that exist in v5.4.51. How
> > many result in conflicts?
> >
> > Could you do the same with v4.19...v4.19.132, which has 20 fixes.
> >
> > This will give us an idea of the maintenance overhead such a change is
> > going to cause, and how good git is at figuring out this sort of
> > thing.
> 
> Okay, I have some fugly bash scripts that use sed to do the majority
> of the work here, save some manual bits done to add duplicate
> interfaces w/new names and some aliases, and everything is compiling
> and functions in a basic smoke test here.
> 
> Summary on the 5.4 git cherry-pick conflict resolution after applying
> changes: not that good. 7 of the 8 bonding fixes in the 5.4 stable
> branch required fixing when straight cherry-picking. Dumping the
> patches, running a sed script over them, and then git am'ing them
> works pretty well though.

Hi Jarad

That is what i was expecting.

I really think that before we consider changes like this, somebody
needs to work on git tooling, so that it knows when mass renames have
happened, and can do the same sort of renames when cherry-picking
across the flag day. Without that, people trying to maintain stable
kernels are going to be very unhappy.

	 Andrew

Re: [RFC] bonding driver terminology change proposal

[Jarod Wilson]

On Wed, Jul 15, 2020 at 11:18 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Wed, Jul 15, 2020 at 11:04:16PM -0400, Jarod Wilson wrote:
> > On Mon, Jul 13, 2020 at 8:26 PM Andrew Lunn <andrew@lunn.ch> wrote:
> > >
> > > Hi Jarod
> > >
> > > Do you have this change scripted? Could you apply the script to v5.4
> > > and then cherry-pick the 8 bonding fixes that exist in v5.4.51. How
> > > many result in conflicts?
> > >
> > > Could you do the same with v4.19...v4.19.132, which has 20 fixes.
> > >
> > > This will give us an idea of the maintenance overhead such a change is
> > > going to cause, and how good git is at figuring out this sort of
> > > thing.
> >
> > Okay, I have some fugly bash scripts that use sed to do the majority
> > of the work here, save some manual bits done to add duplicate
> > interfaces w/new names and some aliases, and everything is compiling
> > and functions in a basic smoke test here.
> >
> > Summary on the 5.4 git cherry-pick conflict resolution after applying
> > changes: not that good. 7 of the 8 bonding fixes in the 5.4 stable
> > branch required fixing when straight cherry-picking. Dumping the
> > patches, running a sed script over them, and then git am'ing them
> > works pretty well though.
>
> Hi Jarad
>
> That is what i was expecting.
>
> I really think that before we consider changes like this, somebody
> needs to work on git tooling, so that it knows when mass renames have
> happened, and can do the same sort of renames when cherry-picking
> across the flag day. Without that, people trying to maintain stable
> kernels are going to be very unhappy.

I'm not familiar enough with git's internals to have a clue where to
begin for something like that, but I suspect you're right. Doing
blanket renames in stable branches sounds like a terrible idea, even
if it would circumvent the cherry-pick issues. I guess now is as good
a time as any to start poking around at git's internals...

-- 
Jarod Wilson
jarod@redhat.com

Re: [RFC] bonding driver terminology change proposal

[David Miller]

From: Jarod Wilson <jarod@redhat.com>
Date: Wed, 15 Jul 2020 23:06:55 -0400

> On Mon, Jul 13, 2020 at 9:00 PM David Miller <davem@davemloft.net> wrote:
>>
>> From: Michal Kubecek <mkubecek@suse.cz>
>> Date: Tue, 14 Jul 2020 00:00:16 +0200
>>
>> > Could we, please, avoid breaking existing userspace tools and scripts?
>>
>> I will not let UAPI breakage, don't worry.
> 
> Seeking some clarification here. Does the output of
> /proc/net/bonding/<bond> fall under that umbrella as well?

Yes, anything user facing must not break.

Re: [RFC] bonding driver terminology change proposal

[Stephen Hemminger]

On Thu, 16 Jul 2020 11:59:47 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

> From: Jarod Wilson <jarod@redhat.com>
> Date: Wed, 15 Jul 2020 23:06:55 -0400
> 
> > On Mon, Jul 13, 2020 at 9:00 PM David Miller <davem@davemloft.net> wrote:  
> >>
> >> From: Michal Kubecek <mkubecek@suse.cz>
> >> Date: Tue, 14 Jul 2020 00:00:16 +0200
> >>  
> >> > Could we, please, avoid breaking existing userspace tools and scripts?  
> >>
> >> I will not let UAPI breakage, don't worry.  
> > 
> > Seeking some clarification here. Does the output of
> > /proc/net/bonding/<bond> fall under that umbrella as well?  
> 
> Yes, anything user facing must not break.
> 

For iproute2, would like better wording on the command
parameters (but accept the old names so as not to break scripts).
The old names can be highlighted as for compatibility only
or removed from the usage manual and usage.

Internally, variable names and function names can change iproute2
since the internal API's are not considered part of user API.

Re: [RFC] bonding driver terminology change proposal

[Jarod Wilson]

On Thu, Jul 16, 2020 at 1:43 AM Jarod Wilson <jarod@redhat.com> wrote:
>
> On Wed, Jul 15, 2020 at 11:18 PM Andrew Lunn <andrew@lunn.ch> wrote:
...
> > I really think that before we consider changes like this, somebody
> > needs to work on git tooling, so that it knows when mass renames have
> > happened, and can do the same sort of renames when cherry-picking
> > across the flag day. Without that, people trying to maintain stable
> > kernels are going to be very unhappy.
>
> I'm not familiar enough with git's internals to have a clue where to
> begin for something like that, but I suspect you're right. Doing
> blanket renames in stable branches sounds like a terrible idea, even
> if it would circumvent the cherry-pick issues. I guess now is as good
> a time as any to start poking around at git's internals...

I haven't forgotten about this, just been tied up with other work. I
spent a bit of time getting lost in git's internals, and the best idea
I've had suggested to me is some sort of cherry-pick hook that
executes an external script to massage variables back to old names for
-stable backporting. Could live somewhere in-tree, and maintainers
would have to know about it, but it would be reasonably painless.
Ideally, I was thinking a semantic patch to filter the backported
patch through, but haven't yet spent enough time playing with
coccinelle to know if that's actually a viable idea, since it's
designed to run on C code, not a patch, as I understand it.
Worst-case, it'd be a shell script doing some awk/sed/whatever.

-- 
Jarod Wilson
jarod@redhat.com