All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>,
	Stephen Hemminger <stephen@networkplumber.org>
Cc: David Ahern <dsahern@kernel.org>, Andrew Lunn <andrew@lunn.ch>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Vivien Didelot <vivien.didelot@gmail.com>
Subject: Re: [PATCH iproute2] ip link: add sub-command to view and change DSA master
Date: Thu, 8 Sep 2022 09:35:03 -0700	[thread overview]
Message-ID: <857e2dd4-cbc6-613c-c8e1-b3ff5d13dc47@gmail.com> (raw)
In-Reply-To: <20220908161104.rcgl3k465ork5vwv@skbuf>



On 9/8/2022 9:11 AM, Vladimir Oltean wrote:
> On Thu, Sep 08, 2022 at 07:25:19AM -0700, Stephen Hemminger wrote:
>> On Thu, 8 Sep 2022 08:08:23 -0600 David Ahern <dsahern@kernel.org> wrote:
>>>> Proposing any alternative naming raises the question how far you want to
>>>> go with the alternative name. No user of DSA knows the "conduit interface"
>>>> or "management port" or whatnot by any other name except "DSA master".
>>>> What do we do about the user-visible Documentation/networking/dsa/configuration.rst,
>>>> which clearly and consistently uses the 'master' name everywhere?
>>>> Do we replace 'master' with something else and act as if it was never
>>>> named 'master' in the first place? Do we introduce IFLA_DSA_MGMT_PORT as
>>>> UAPI and explain in the documentation "oh yeah, that's how you change
>>>> the DSA master"? "Ahh ok, why didn't you just call it IFLA_DSA_MASTER
>>>> then?" "Well...."
>>>>
>>>> Also, what about the code in net/dsa/*.c and drivers/net/dsa/, do we
>>>> also change that to reflect the new terminology, or do we just have
>>>> documentation stating one thing and the code another?
>>>>
>>>> At this stage, I'm much more likely to circumvent all of this, and avoid
>>>> triggering anyone by making a writable IFLA_LINK be the mechanism through
>>>> which we change the DSA master.
>>>
>>> IMHO, 'master' should be an allowed option giving the precedence of
>>> existing code and existing terminology. An alternative keyword can be
>>> used for those that want to avoid use of 'master' in scripts. vrf is an
>>> example of this -- you can specify 'vrf <device>' as a keyword instead
>>> of 'master <vrf>'
>>
>> Agreed, just wanted to start discussion of alternative wording.
> 
> So are we or are we not in the clear with IFLA_DSA_MASTER and
> "ip link set ... type dsa master ..."? What does being in the clear even
> mean technically, and where can I find more details about the policy
> which you just mentioned? Like is it optional or mandatory, was there
> any public debate surrounding the motivation for flagging some words,
> how is it enforced, are there official exceptions, etc?

The "bonding" driver topic has some good context:

https://lkml.iu.edu/hypermail/linux/kernel/2010.0/02186.html
-- 
Florian

  reply	other threads:[~2022-09-08 16:35 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-04 19:00 [PATCH iproute2] ip link: add sub-command to view and change DSA master Vladimir Oltean
2022-09-06 15:29 ` Stephen Hemminger
2022-09-06 16:41   ` Vladimir Oltean
2022-09-06 16:55     ` Stephen Hemminger
2022-09-06 19:13       ` Vladimir Oltean
2022-09-06 20:05         ` Andrew Lunn
2022-09-06 20:33           ` Florian Fainelli
2022-09-06 21:17             ` Stephen Hemminger
2022-09-06 21:34               ` Florian Fainelli
2022-09-06 21:37               ` Andrew Lunn
2022-09-08 12:51             ` Vladimir Oltean
2022-09-08 14:08               ` David Ahern
2022-09-08 14:25                 ` Stephen Hemminger
2022-09-08 16:11                   ` Vladimir Oltean
2022-09-08 16:35                     ` Florian Fainelli [this message]
2022-09-08 16:39                       ` Stephen Hemminger
2022-09-09  6:09                     ` Benjamin Poirier
2022-09-09 11:23                       ` Vladimir Oltean
2022-09-09 15:03                       ` Stephen Hemminger

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=857e2dd4-cbc6-613c-c8e1-b3ff5d13dc47@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=dsahern@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.org \
    --cc=vivien.didelot@gmail.com \
    --cc=vladimir.oltean@nxp.com \
    /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.