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]
Message-Id: <20201002.155312.133560326274339745.davem@davemloft.net>
Date:   Fri, 02 Oct 2020 15:53:12 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     stephen@...workplumber.org
Cc:     jarod@...hat.com, linux-kernel@...r.kernel.org,
        j.vosburgh@...il.com, vfalico@...il.com, andy@...yhouse.net,
        kuba@...nel.org, tadavis@....gov, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 6/6] bonding: make Kconfig toggle to
 disable legacy interfaces

From: Stephen Hemminger <stephen@...workplumber.org>
Date: Fri, 2 Oct 2020 12:13:17 -0700

> On Fri,  2 Oct 2020 13:40:01 -0400
> Jarod Wilson <jarod@...hat.com> wrote:
> 
>> By default, enable retaining all user-facing API that includes the use of
>> master and slave, but add a Kconfig knob that allows those that wish to
>> remove it entirely do so in one shot.
> 
> This is problematic. You are printing both old and new values.
> Also every distribution will have to enable it.
> 
> This looks like too much of change to users.

Agreed, no Kconfig knob.

Keep everything during the deprecation period, then you can kill off
the old names at the end of the deprecation period.

I don't want to create a situation where distribution X lists as a
"feature" that they are able to enable this Kconfig value even though
it breaks UAPI for legacy external code out there.

That's the wrong way to go about this and creates the wrong incentive
system.

I also agree that you can't change the docs to stop mentioning the old
names.  It's almost like we are pretending we aren't doing the
transition and that only the new names matter.  The old names matter
and must therefore be acknowledged, exist, and be referencable in the
documentation until the end of the deprecation period.  You can mark
them "(DEPRECATED)" or similar, but they can't be removed just yet.

Thank you.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ