Message-ID: <20200610060727.q4nzryh3mp6fj2ax@pengutronix.de>
Date:   Wed, 10 Jun 2020 08:07:27 +0200
From:   Oleksij Rempel <o.rempel@...gutronix.de>
To:     Dan Williams <dan.j.williams@...el.com>
Cc:     David Miller <davem@...emloft.net>, marex@...x.de,
        Andrew Lunn <andrew@...n.ch>, mkubecek@...e.cz,
        f.fainelli@...il.com, Jonathan Corbet <corbet@....net>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        Netdev <netdev@...r.kernel.org>, linville@...driver.com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Stephen Hemminger <stephen@...workplumber.org>,
        kuba@...nel.org, mkl@...gutronix.de, kernel@...gutronix.de,
        david@...tonic.nl, amitc@...lanox.com, petrm@...lanox.com,
        christian.herber@....com, hkallweit1@...il.com
Subject: Re: [PATCH ethtool v1] netlink: add master/slave configuration
 support

On Tue, Jun 09, 2020 at 02:48:51PM -0700, Dan Williams wrote:
> On Tue, Jun 9, 2020 at 12:57 PM David Miller <davem@...emloft.net> wrote:
> >
> > From: "Williams, Dan J" <dan.j.williams@...el.com>
> > Date: Tue, 9 Jun 2020 19:30:50 +0000
> >
> > > On Tue, 2020-06-09 at 11:36 -0700, David Miller wrote:
> > >> From: Stephen Hemminger <stephen@...workplumber.org>
> > >> Date: Tue, 9 Jun 2020 10:19:35 -0700
> > >>
> > >> > Yes, words do matter and convey a lot of implied connotation and
> > >> > meaning.
> > >>
> > >> What is your long term plan?  Will you change all of the UAPI for
> > >> bonding for example?
> > >
> > > The long term plan in my view includes talking with standards bodies to
> > > move new content to, for example, master/subordinate. In other words,
> > > practical forward steps, not retroactively changing interfaces.
> >
> > When that knowledge is established legitimately in standards and
> > transferred into common knowledge of these technologies, yes then
> > please come present your proposals.
> 
> Our hands are not completely tied by the specifications, as a
> community we have a non-zero level of influence over standards bodies,
> even direct participation in some. So we could do something stronger
> than passively wait for standards to catch up. For example, deprecate
> our consideration of future specifications that include this language
> and set a cut off date.
> 
> I understand the confusion that arises from using terminology
> differently from the specification, but at the same time when
> specification language actively hurts kernel code maintainability we
> change it. For example, when I did the first iteration of what
> eventually became libnvdimm Ingo rightly reacted to the naming being
> too ACPI specification centric and wanting more kernel-centric naming.
> 
> If the common kernel name for what was formerly called a "slave"
> device is a "subordinate" device then the confusion is lessened, only
> one common kernel translation to consider.
> 
> > But right now using different words will create confusion.
> >
> > I also find master/subordinate an interesting proposal, what if master
> > is a triggering term?  Why only slave?
> 
> "slave" has a direct connection to human suffering deployed at global scale.
> 
> One way I think about this is consider we have our first ever Linux
> Plumbers on the African continent, and you had a choice about giving a
> talk about how the git master branch operates, or a talk about slave
> devices which one would you feel more immediately comfortable leading?
> Any hesitation you would feel freely using the word slave with a
> predominantly black audience is a similar speed bump a contributor
> might feel needing to consume that term to get their job done.
> 
> Explaining "no, not that connotation of slave" does not scale as much
> as transitioning to another term.
> 
> > I know people feel something needs to change, but do that moving
> > forward for the technologies themselves.
> 
> This is the start of a process that the kernel community can take an
> active role to lead, we have it within our control to not wait for the
> lowest common denominator to catch up.
> 
> > Not how we implement support
> > for a technology which is established already.
> >
> > Plant the seed, don't chop the tree down.
> 
> I appreciate the engagement.

It is interesting to see technical mind arguing about humanitarian
topics. Usually I need to translate IT to theologies, historic teachers
or linguists. So, let me try to do it other way around:

- a language is not a snapshot. The meaning of words is changing
  continually. For example, an ARM is buying Intel networking division and all
  i200 controller should be renamed to arm100..
  I'm not familiar with your local history, so i give some examples to
  German readers:
  - The word "Führer" was abused by some historical person and event.
  - The word "geil" is changed within one generation from sexual
    erection to a positive emotion reusable in almost every context.
  There is many language changes just within last century, please refer
  to DUDEN to learn more about it:
  https://www.duden.de/ueber_duden/auflagengeschichte
  Or for more generic examples:
  https://en.wikipedia.org/wiki/Language_change

- from your argumentation I would assume, you are trying to define a
  language. A language not historically misused, so it will be
  acceptable by every one. Or at least by the technical community.
  Suddenly, I should disappoint you. The number of programming
  languages defined by technical community is is still growing and none of it
  makes happy every one. How do you thing the reality looks for spoken language?
  Welcome to my reality:
  https://en.wikipedia.org/wiki/Universal_language
  In case the historical argumentations are too boring, let me give you
  a modern, less boring example:
  https://youtu.be/7C-aB09i30E

- Are there any other attempts to change historical and linguistic
  reality by removing and replacing something? Sure:
  https://en.wikipedia.org/wiki/Book_burning


Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists