From: Michal Kubecek <mkubecek@suse.cz>
To: netdev@vger.kernel.org
Cc: Stephen Hemminger <stephen@networkplumber.org>,
Jarod Wilson <jarod@redhat.com>
Subject: Re: [RFC] bonding driver terminology change proposal
Date: Tue, 14 Jul 2020 02:09:49 +0200 [thread overview]
Message-ID: <20200714000949.txckjqlp4rzku3q3@lion.mk-sys.cz> (raw)
In-Reply-To: <20200713154118.3a1edd66@hermes.lan>
On Mon, Jul 13, 2020 at 03:41:18PM -0700, Stephen Hemminger wrote:
> On Tue, 14 Jul 2020 00:00:16 +0200
> Michal Kubecek <mkubecek@suse.cz> wrote:
>
> > On Mon, Jul 13, 2020 at 02:51:39PM -0400, Jarod Wilson wrote:
> > > To start out with, I'd like to attempt to eliminate as much of the use
> > > of master and slave in the bonding driver as possible. For the most
> > > part, I think this can be done without breaking UAPI, but may require
> > > changes to anything accessing bond info via proc or sysfs.
> >
> > Could we, please, avoid breaking existing userspace tools and scripts?
> > Massive code churn is one thing and we could certainly bite the bullet
> > and live with it (even if I'm still not convinced it would be as great
> > idea as some present it) but trading theoretical offense for real and
> > palpable harm to existing users is something completely different.
> >
> > Or is "don't break userspace" no longer the "first commandment" of linux
> > kernel development?
> >
> > Michal Kubecek
>
> Please consider using same wording as current standard for link aggregration.
> Current version is 802.1AX and it uses the terms:
> Multiplexer / Aggregator
But both of these are replacements for "master", right?
> As far as userspace, maybe keep the old API's but provide deprecation nags.
> And don't document the old API values.
I'm not a fan of nagging users. And even less of a fan of undocumented
keyword and value aliases.
Michal
next prev parent reply other threads:[~2020-07-14 0:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-13 18:51 [RFC] bonding driver terminology change proposal Jarod Wilson
2020-07-13 21:36 ` Eric Dumazet
2020-07-14 18:01 ` Jarod Wilson
2020-07-13 22:00 ` Michal Kubecek
2020-07-13 22:41 ` Stephen Hemminger
2020-07-14 0:09 ` Michal Kubecek [this message]
2020-07-14 0:26 ` Andrew Lunn
2020-07-16 3:04 ` Jarod Wilson
2020-07-16 3:18 ` Andrew Lunn
2020-07-16 5:43 ` Jarod Wilson
2020-08-13 3:42 ` Jarod Wilson
2020-07-14 0:55 ` Jay Vosburgh
2020-07-14 18:15 ` Jarod Wilson
2020-07-15 12:56 ` Edward Cree
2020-07-15 19:23 ` Jarod Wilson
2020-07-14 1:00 ` David Miller
2020-07-16 3:06 ` Jarod Wilson
2020-07-16 18:59 ` David Miller
2020-07-16 23:01 ` Stephen Hemminger
2020-07-14 18:04 ` Jarod Wilson
2020-07-14 0:51 ` David Miller
2020-07-14 19:17 ` Toke Høiland-Jørgensen
2020-07-14 20:39 ` Marcelo Ricardo Leitner
2020-07-14 21:24 ` Jarod Wilson
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=20200714000949.txckjqlp4rzku3q3@lion.mk-sys.cz \
--to=mkubecek@suse.cz \
--cc=jarod@redhat.com \
--cc=netdev@vger.kernel.org \
--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).