netdev - Re: [RFC] bonding driver terminology change proposal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 14 Jul 2020 02:09:49 +0200
From:   Michal Kubecek <mkubecek@...e.cz>
To:     netdev@...r.kernel.org
Cc:     Stephen Hemminger <stephen@...workplumber.org>,
        Jarod Wilson <jarod@...hat.com>
Subject: Re: [RFC] bonding driver terminology change proposal

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@...e.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