netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Kubecek <mkubecek@suse.cz>
To: netdev@vger.kernel.org
Cc: Stephen Hemminger <stephen@networkplumber.org>,
	David Miller <davem@davemloft.net>,
	o.rempel@pengutronix.de, andrew@lunn.ch, f.fainelli@gmail.com,
	hkallweit1@gmail.com, kuba@kernel.org, corbet@lwn.net,
	linville@tuxdriver.com, david@protonic.nl, kernel@pengutronix.de,
	linux-kernel@vger.kernel.org, linux@armlinux.org.uk,
	mkl@pengutronix.de, marex@denx.de, christian.herber@nxp.com,
	amitc@mellanox.com, petrm@mellanox.com
Subject: Re: [PATCH ethtool v1] netlink: add master/slave configuration support
Date: Tue, 9 Jun 2020 22:31:27 +0200	[thread overview]
Message-ID: <20200609203127.aivc3tq4lq4bh6dt@lion.mk-sys.cz> (raw)
In-Reply-To: <20200609101935.5716b3bd@hermes.lan>

On Tue, Jun 09, 2020 at 10:19:35AM -0700, Stephen Hemminger wrote:
> On Sun, 07 Jun 2020 16:45:32 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
> 
> > From: Stephen Hemminger <stephen@networkplumber.org>
> > Date: Sun, 7 Jun 2020 15:30:19 -0700
> > 
> > > Open source projects have been working hard to remove the terms master and slave
> > > in API's and documentation. Apparently, Linux hasn't gotten the message.
> > > It would make sense not to introduce new instances.  
> > 
> > Would you also be against, for example, the use of the terminology
> > expressing the "death" of allocated registers in a compiler backend,
> > for example?
> > 
> > How far do you plan take this resistence of terminology when it
> > clearly has a well defined usage and meaning in a specific technical
> > realm which is entirely disconnected to what the terms might imply,
> > meaning wise, in other realms?
> > 
> > And if you are going to say not to use this terminology, you must
> > suggest a reasonable (and I do mean _reasonable_) well understood
> > and _specific_ replacement.
> > 
> > Thank you.
> 
> How many times have you or Linus argued about variable naming.
> Yes, words do matter and convey a lot of implied connotation and meaning.
> 
> Most projects and standards bodies are taking a stance on fixing the
> language. The IETF is has proposed making changes as well.
> 
> There are a very specific set of trigger words and terms that
> should be fixed. Most of these terms do have better alternatives.

Where can this list be found and who is the authority to determine what
should be on this list? I could think of a long list of technical terms
which could be seen as offensive in certain context. Some would feel
just as obvious as master/slave, some would be borderline absurd, most
somewhere between. Who has the authority to define what is acceptable
and what not?

Words can have very different meaning and raise different emotions,
depending on context. Even an innocuous word like "black" can be
offensive in certain context; is it a reason to stop talking about this
color or to invent a new name for it? I don't think so - and for obvious
reasons, it wouldn't help anyway. Should we rename rbtrees because of
that? I don't think so either.

The primary purpose of technical terms is to allow people to communicate
and to express themselves in a way that will be easy to understand for
others working in the field. Inventing our own terms which would differ
both from existing relevant standards and from what people in the
industry have been using for decades would not help anything; it would
only make life of ethtool users harder.

> A common example is that master/slave is unclear and would be clearer
> as primary/secondary or active/backup or controller/worker.
> 
> Most of networking is based on standards. When the standards wording changes
> (and it will happen soon); then Linux should also change the wording in the
> source, api and documentation.

Even if you are right about the upcoming change of IEEE standards (and
I can't say I'm convinced), it would make little sense to invent some
replacement terms now and risk that IEEE chooses something else. Waiting
for the standard change (which might take years - or might not even
happen at all) and not providing support for the feature doesn't seem
like a good solution either.

So what exactly would you like us to do?

Michal

      parent reply	other threads:[~2020-06-09 20:31 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-26  9:10 [PATCH ethtool v1] netlink: add master/slave configuration support Oleksij Rempel
2020-05-26 12:41 ` Michal Kubecek
2020-05-27 10:26   ` Oleksij Rempel
2020-06-07 22:30 ` Stephen Hemminger
2020-06-07 23:45   ` David Miller
2020-06-09 17:19     ` Stephen Hemminger
2020-06-09 18:30       ` Andrew Lunn
2020-06-09 18:36       ` David Miller
2020-06-09 19:29         ` Kees Cook
2020-06-09 19:34           ` David Miller
2020-06-09 19:49             ` Kees Cook
2020-06-09 20:05               ` David Miller
2020-06-09 20:29                 ` Kees Cook
2020-06-09 20:53                   ` Michal Kubecek
2020-06-09 21:34                     ` Kees Cook
2020-06-09 19:30         ` Williams, Dan J
2020-06-09 19:38           ` David Miller
2020-06-09 21:48             ` Dan Williams
2020-06-10  6:07               ` Oleksij Rempel
2020-06-09 18:46       ` Edward Cree
2020-06-09 20:31       ` Michal Kubecek [this message]

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=20200609203127.aivc3tq4lq4bh6dt@lion.mk-sys.cz \
    --to=mkubecek@suse.cz \
    --cc=amitc@mellanox.com \
    --cc=andrew@lunn.ch \
    --cc=christian.herber@nxp.com \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=david@protonic.nl \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linville@tuxdriver.com \
    --cc=marex@denx.de \
    --cc=mkl@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=petrm@mellanox.com \
    --cc=stephen@networkplumber.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 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).