* [RFC] bonding driver terminology change proposal @ 2020-07-13 18:51 Jarod Wilson 2020-07-13 21:36 ` Eric Dumazet ` (3 more replies) 0 siblings, 4 replies; 24+ messages in thread From: Jarod Wilson @ 2020-07-13 18:51 UTC (permalink / raw) To: Netdev 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-13 18:51 [RFC] bonding driver terminology change proposal Jarod Wilson @ 2020-07-13 21:36 ` Eric Dumazet 2020-07-14 18:01 ` Jarod Wilson 2020-07-13 22:00 ` Michal Kubecek ` (2 subsequent siblings) 3 siblings, 1 reply; 24+ messages in thread From: Eric Dumazet @ 2020-07-13 21:36 UTC (permalink / raw) To: Jarod Wilson, Netdev 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 :/ ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-13 21:36 ` Eric Dumazet @ 2020-07-14 18:01 ` Jarod Wilson 0 siblings, 0 replies; 24+ messages in thread From: Jarod Wilson @ 2020-07-14 18:01 UTC (permalink / raw) To: Eric Dumazet; +Cc: Netdev 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-13 18:51 [RFC] bonding driver terminology change proposal Jarod Wilson 2020-07-13 21:36 ` Eric Dumazet @ 2020-07-13 22:00 ` Michal Kubecek 2020-07-13 22:41 ` Stephen Hemminger ` (2 more replies) 2020-07-14 0:51 ` David Miller 2020-07-14 19:17 ` Toke Høiland-Jørgensen 3 siblings, 3 replies; 24+ messages in thread From: Michal Kubecek @ 2020-07-13 22:00 UTC (permalink / raw) To: netdev; +Cc: Jarod Wilson 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-13 22:00 ` Michal Kubecek @ 2020-07-13 22:41 ` Stephen Hemminger 2020-07-14 0:09 ` Michal Kubecek ` (3 more replies) 2020-07-14 1:00 ` David Miller 2020-07-14 18:04 ` Jarod Wilson 2 siblings, 4 replies; 24+ messages in thread From: Stephen Hemminger @ 2020-07-13 22:41 UTC (permalink / raw) To: Michal Kubecek; +Cc: netdev, Jarod Wilson 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-13 22:41 ` Stephen Hemminger @ 2020-07-14 0:09 ` Michal Kubecek 2020-07-14 0:26 ` Andrew Lunn ` (2 subsequent siblings) 3 siblings, 0 replies; 24+ messages in thread From: Michal Kubecek @ 2020-07-14 0:09 UTC (permalink / raw) To: netdev; +Cc: Stephen Hemminger, Jarod Wilson 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-13 22:41 ` Stephen Hemminger 2020-07-14 0:09 ` Michal Kubecek @ 2020-07-14 0:26 ` Andrew Lunn 2020-07-16 3:04 ` Jarod Wilson 2020-07-14 0:55 ` Jay Vosburgh 2020-07-15 12:56 ` Edward Cree 3 siblings, 1 reply; 24+ messages in thread From: Andrew Lunn @ 2020-07-14 0:26 UTC (permalink / raw) To: Jarod Wilson; +Cc: netdev 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-14 0:26 ` Andrew Lunn @ 2020-07-16 3:04 ` Jarod Wilson 2020-07-16 3:18 ` Andrew Lunn 0 siblings, 1 reply; 24+ messages in thread From: Jarod Wilson @ 2020-07-16 3:04 UTC (permalink / raw) To: Andrew Lunn; +Cc: Netdev 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-16 3:04 ` Jarod Wilson @ 2020-07-16 3:18 ` Andrew Lunn 2020-07-16 5:43 ` Jarod Wilson 0 siblings, 1 reply; 24+ messages in thread From: Andrew Lunn @ 2020-07-16 3:18 UTC (permalink / raw) To: Jarod Wilson; +Cc: Netdev 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-16 3:18 ` Andrew Lunn @ 2020-07-16 5:43 ` Jarod Wilson 2020-08-13 3:42 ` Jarod Wilson 0 siblings, 1 reply; 24+ messages in thread From: Jarod Wilson @ 2020-07-16 5:43 UTC (permalink / raw) To: Andrew Lunn; +Cc: Netdev 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-16 5:43 ` Jarod Wilson @ 2020-08-13 3:42 ` Jarod Wilson 0 siblings, 0 replies; 24+ messages in thread From: Jarod Wilson @ 2020-08-13 3:42 UTC (permalink / raw) To: Andrew Lunn; +Cc: Netdev 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-13 22:41 ` Stephen Hemminger 2020-07-14 0:09 ` Michal Kubecek 2020-07-14 0:26 ` Andrew Lunn @ 2020-07-14 0:55 ` Jay Vosburgh 2020-07-14 18:15 ` Jarod Wilson 2020-07-15 12:56 ` Edward Cree 3 siblings, 1 reply; 24+ messages in thread From: Jay Vosburgh @ 2020-07-14 0:55 UTC (permalink / raw) To: Stephen Hemminger; +Cc: Michal Kubecek, netdev, Jarod Wilson 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-14 0:55 ` Jay Vosburgh @ 2020-07-14 18:15 ` Jarod Wilson 0 siblings, 0 replies; 24+ messages in thread From: Jarod Wilson @ 2020-07-14 18:15 UTC (permalink / raw) To: Jay Vosburgh; +Cc: Stephen Hemminger, Michal Kubecek, Netdev 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-13 22:41 ` Stephen Hemminger ` (2 preceding siblings ...) 2020-07-14 0:55 ` Jay Vosburgh @ 2020-07-15 12:56 ` Edward Cree 2020-07-15 19:23 ` Jarod Wilson 3 siblings, 1 reply; 24+ messages in thread From: Edward Cree @ 2020-07-15 12:56 UTC (permalink / raw) To: Stephen Hemminger, Michal Kubecek; +Cc: netdev, Jarod Wilson 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-15 12:56 ` Edward Cree @ 2020-07-15 19:23 ` Jarod Wilson 0 siblings, 0 replies; 24+ messages in thread From: Jarod Wilson @ 2020-07-15 19:23 UTC (permalink / raw) To: Edward Cree; +Cc: Stephen Hemminger, Michal Kubecek, Netdev 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-13 22:00 ` Michal Kubecek 2020-07-13 22:41 ` Stephen Hemminger @ 2020-07-14 1:00 ` David Miller 2020-07-16 3:06 ` Jarod Wilson 2020-07-14 18:04 ` Jarod Wilson 2 siblings, 1 reply; 24+ messages in thread From: David Miller @ 2020-07-14 1:00 UTC (permalink / raw) To: mkubecek; +Cc: netdev, jarod 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-14 1:00 ` David Miller @ 2020-07-16 3:06 ` Jarod Wilson 2020-07-16 18:59 ` David Miller 0 siblings, 1 reply; 24+ messages in thread From: Jarod Wilson @ 2020-07-16 3:06 UTC (permalink / raw) To: David Miller; +Cc: Michal Kubecek, Netdev 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-16 3:06 ` Jarod Wilson @ 2020-07-16 18:59 ` David Miller 2020-07-16 23:01 ` Stephen Hemminger 0 siblings, 1 reply; 24+ messages in thread From: David Miller @ 2020-07-16 18:59 UTC (permalink / raw) To: jarod; +Cc: mkubecek, netdev 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-16 18:59 ` David Miller @ 2020-07-16 23:01 ` Stephen Hemminger 0 siblings, 0 replies; 24+ messages in thread From: Stephen Hemminger @ 2020-07-16 23:01 UTC (permalink / raw) To: David Miller; +Cc: jarod, mkubecek, netdev 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-13 22:00 ` Michal Kubecek 2020-07-13 22:41 ` Stephen Hemminger 2020-07-14 1:00 ` David Miller @ 2020-07-14 18:04 ` Jarod Wilson 2 siblings, 0 replies; 24+ messages in thread From: Jarod Wilson @ 2020-07-14 18:04 UTC (permalink / raw) To: Michal Kubecek; +Cc: Netdev 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-13 18:51 [RFC] bonding driver terminology change proposal Jarod Wilson 2020-07-13 21:36 ` Eric Dumazet 2020-07-13 22:00 ` Michal Kubecek @ 2020-07-14 0:51 ` David Miller 2020-07-14 19:17 ` Toke Høiland-Jørgensen 3 siblings, 0 replies; 24+ messages in thread From: David Miller @ 2020-07-14 0:51 UTC (permalink / raw) To: jarod; +Cc: netdev 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-13 18:51 [RFC] bonding driver terminology change proposal Jarod Wilson ` (2 preceding siblings ...) 2020-07-14 0:51 ` David Miller @ 2020-07-14 19:17 ` Toke Høiland-Jørgensen 2020-07-14 20:39 ` Marcelo Ricardo Leitner 3 siblings, 1 reply; 24+ messages in thread From: Toke Høiland-Jørgensen @ 2020-07-14 19:17 UTC (permalink / raw) To: Jarod Wilson, Netdev 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-14 19:17 ` Toke Høiland-Jørgensen @ 2020-07-14 20:39 ` Marcelo Ricardo Leitner 2020-07-14 21:24 ` Jarod Wilson 0 siblings, 1 reply; 24+ messages in thread From: Marcelo Ricardo Leitner @ 2020-07-14 20:39 UTC (permalink / raw) To: Toke Høiland-Jørgensen; +Cc: Jarod Wilson, Netdev 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC] bonding driver terminology change proposal 2020-07-14 20:39 ` Marcelo Ricardo Leitner @ 2020-07-14 21:24 ` Jarod Wilson 0 siblings, 0 replies; 24+ messages in thread From: Jarod Wilson @ 2020-07-14 21:24 UTC (permalink / raw) To: Marcelo Ricardo Leitner; +Cc: Toke Høiland-Jørgensen, Netdev 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2020-08-13 3:43 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-07-13 18:51 [RFC] bonding driver terminology change proposal Jarod Wilson 2020-07-13 21:36 ` Eric Dumazet 2020-07-14 18:01 ` Jarod Wilson 2020-07-13 22:00 ` Michal Kubecek 2020-07-13 22:41 ` Stephen Hemminger 2020-07-14 0:09 ` Michal Kubecek 2020-07-14 0:26 ` Andrew Lunn 2020-07-16 3:04 ` Jarod Wilson 2020-07-16 3:18 ` Andrew Lunn 2020-07-16 5:43 ` Jarod Wilson 2020-08-13 3:42 ` Jarod Wilson 2020-07-14 0:55 ` Jay Vosburgh 2020-07-14 18:15 ` Jarod Wilson 2020-07-15 12:56 ` Edward Cree 2020-07-15 19:23 ` Jarod Wilson 2020-07-14 1:00 ` David Miller 2020-07-16 3:06 ` Jarod Wilson 2020-07-16 18:59 ` David Miller 2020-07-16 23:01 ` Stephen Hemminger 2020-07-14 18:04 ` Jarod Wilson 2020-07-14 0:51 ` David Miller 2020-07-14 19:17 ` Toke Høiland-Jørgensen 2020-07-14 20:39 ` Marcelo Ricardo Leitner 2020-07-14 21:24 ` Jarod Wilson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).