Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 9 Jun 2020 13:29:42 -0700
From:   Kees Cook <keescook@chromium.org>
To:     David Miller <davem@davemloft.net>
Cc:     stephen@networkplumber.org, o.rempel@pengutronix.de,
        andrew@lunn.ch, f.fainelli@gmail.com, hkallweit1@gmail.com,
        kuba@kernel.org, corbet@lwn.net, mkubecek@suse.cz,
        linville@tuxdriver.com, david@protonic.nl, kernel@pengutronix.de,
        linux-kernel@vger.kernel.org, netdev@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
Message-ID: <202006091312.F91BB4E0CE@keescook>
References: <202006091222.CB97F743AD@keescook>
 <20200609.123437.1057990370119930723.davem@davemloft.net>
 <202006091244.C8B5F9525@keescook>
 <20200609.130517.1373472507830142138.davem@davemloft.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200609.130517.1373472507830142138.davem@davemloft.net>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Jun 09, 2020 at 01:05:17PM -0700, David Miller wrote:
> From: Kees Cook <keescook@chromium.org>
> Date: Tue, 9 Jun 2020 12:49:48 -0700
> 
> > Okay, for now, how about:
> > 
> > - If we're dealing with an existing spec, match the language.
> 
> Yes.
> 
> > - If we're dealing with a new spec, ask the authors to fix their language.
> 
> Please be more specific about "new", if it's a passed and ratified standard
> then to me it is "existing".

Sure. But many kernel devs are also interacting with specifications as
they're being developed. We can have an eye out for this when we're in
such positions.

> > - If a new version of a spec has updated its language, adjust the kernel's.
> 
> Unless you're willing to break UAPI, which I'm not, I don't see how this is
> tenable.

We'll get there when we get there. I honestly don't think any old spec is
actually going to change their language; I look forward to being proven
wrong. But many times there is no UAPI. If it's some register states
between driver and hardware, no users sees or cares what the register
is named.

> > - If we're doing with something "internal" to the kernel (including UAPI),
> >   stop adding new instances.
> 
> Even if it is part of supporting a technology where the standard uses
> those terms?  So we'll use inconsitent terms internally?

What? I mean "internal" in the sense of "does not have an external
dependency". Maybe I should say "independent"?

> This is why I'm saying, just make sure new specs use language that is
> less controversial.  Then we just use what the specs use.
> 
> Then you don't have to figure out what to do about established UAPIs
> and such, it's a non-issue.

Yes, but there are places where people use these terms where they are
NOT part of specs, and usually there is actually _better_ terminology
to be used, and we can easily stop adding those. And we can start to
rename old "independent" cases too.

For example, if MS_SLAVE were being added now, we would rename it.

-- 
Kees Cook