From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: Jarod Wilson <jarod@redhat.com>, Netdev <netdev@vger.kernel.org>
Subject: Re: [RFC] bonding driver terminology change proposal
Date: Tue, 14 Jul 2020 17:39:15 -0300 [thread overview]
Message-ID: <20200714203915.GK74252@localhost.localdomain> (raw)
In-Reply-To: <87y2nlgb37.fsf@toke.dk>
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
next prev parent reply other threads:[~2020-07-14 20:39 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2020-07-14 21:24 ` Jarod Wilson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200714203915.GK74252@localhost.localdomain \
--to=marcelo.leitner@gmail.com \
--cc=jarod@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=toke@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).