netdev - Re: [PATCH net-next v2 6/6] bonding: make Kconfig toggle to disable legacy interfaces

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:   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.