All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarod Wilson <jarod@redhat.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Netdev <netdev@vger.kernel.org>
Subject: Re: [RFC] bonding driver terminology change proposal
Date: Tue, 14 Jul 2020 14:01:07 -0400	[thread overview]
Message-ID: <CAKfmpScwe_mv+Tm9sXyJqXk7bs8-ZWbNq0025Lcho_VK6qZNMw@mail.gmail.com> (raw)
In-Reply-To: <7fb02008-e469-38b7-735b-6bfb8beab414@gmail.com>

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


  reply	other threads:[~2020-07-14 18:01 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 [this message]
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

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=CAKfmpScwe_mv+Tm9sXyJqXk7bs8-ZWbNq0025Lcho_VK6qZNMw@mail.gmail.com \
    --to=jarod@redhat.com \
    --cc=eric.dumazet@gmail.com \
    --cc=netdev@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.