Netdev Archive on lore.kernel.org
 help / color / Atom feed
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
Date: Tue, 9 Jun 2020 13:29:42 -0700
Message-ID: <202006091312.F91BB4E0CE@keescook> (raw)
In-Reply-To: <20200609.130517.1373472507830142138.davem@davemloft.net>

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

  reply index

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-26  9:10 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 [this message]
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

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=202006091312.F91BB4E0CE@keescook \
    --to=keescook@chromium.org \
    --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=mkubecek@suse.cz \
    --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

Netdev Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/netdev/0 netdev/git/0.git
	git clone --mirror https://lore.kernel.org/netdev/1 netdev/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 netdev netdev/ https://lore.kernel.org/netdev \
		netdev@vger.kernel.org
	public-inbox-index netdev

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.netdev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git