Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1660584pxk; Fri, 2 Oct 2020 15:54:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJytL8b2oE9xvF/pYhosnp/6gFHN30twcS6WV3SeoCMHzvzSn/A4mZltP6A9HLxy3qviJTWB X-Received: by 2002:a17:906:1955:: with SMTP id b21mr4532713eje.42.1601679293232; Fri, 02 Oct 2020 15:54:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601679293; cv=none; d=google.com; s=arc-20160816; b=a0l7eyl67sLLq0fzatSn6iZQf1eQuvZft/ucphbwSk85Z7SnAB1KcQcYNryiHSW2AU Ix3entlNMsYDF/3jpk/KuRbU7B2L5Jut+G617I74K2VCnrmX8wmLPeQsMaLa3wRrkF/c NLEjGF2WCspyDuxfcTBGMszazqZBWvRy4V/f89Jfbd+eeyUfOz0wbeu8r/4W+3EjL0Jv k39aIgetNOVuNDvr7qfu9wJLwKejXHpYAruSKU0FDse7i0mHCFAFlSfe7r3G0EW1dyFc 4Hsskana0DtMbY9kqpQti3y9GIlRFp4YEXxCKfsch5o9bGqHfMQAOcV5kp/Hi5D6mKWM XYgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=vzQYVGrPsHPiuoNODedySzSBsyZWQNdxeGPNiSeZn/o=; b=s+wKozirh+pPYwfktMRQU1QRmkY8Hs86L9zHBd+UqZ2S8ja1+SimlLIhjQ/xx5l+Nf UnNEAW3BY7fpFp4MdKh9JBD32+2IFG3gY8jZCGADc8ThpSbnRFCKExmYQPQgSVPL4D/M x/X3geXGS407kK8dd+f8l2Co/xSiZjzTI/kn/ul+8lzm7TiDOo1/yj24t/XdPS4Bfk+I cd6Ydw3CwkdBdlpcYWOydqgc+Ur3U218JSHcQrK3fxqGmzpXDTqWUIUhev/QtYbfQ9NH hyy0Mjv9KkLlLcExTmoOukOGYet8CTInF7T7tpdp+HWP7JGBuNFxeS1cAOnyxKIfEZNZ J2+A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v11si1899309edx.325.2020.10.02.15.54.29; Fri, 02 Oct 2020 15:54:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725769AbgJBWxO (ORCPT + 99 others); Fri, 2 Oct 2020 18:53:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48158 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725536AbgJBWxO (ORCPT ); Fri, 2 Oct 2020 18:53:14 -0400 Received: from shards.monkeyblade.net (shards.monkeyblade.net [IPv6:2620:137:e000::1:9]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8D363C0613D0; Fri, 2 Oct 2020 15:53:14 -0700 (PDT) Received: from localhost (unknown [IPv6:2601:601:9f00:477::3d5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id E48B911E4981C; Fri, 2 Oct 2020 15:36:25 -0700 (PDT) Date: Fri, 02 Oct 2020 15:53:12 -0700 (PDT) Message-Id: <20201002.155312.133560326274339745.davem@davemloft.net> To: stephen@networkplumber.org Cc: jarod@redhat.com, linux-kernel@vger.kernel.org, j.vosburgh@gmail.com, vfalico@gmail.com, andy@greyhouse.net, kuba@kernel.org, tadavis@lbl.gov, netdev@vger.kernel.org Subject: Re: [PATCH net-next v2 6/6] bonding: make Kconfig toggle to disable legacy interfaces From: David Miller In-Reply-To: <20201002121317.474c95f0@hermes.local> References: <20201002174001.3012643-1-jarod@redhat.com> <20201002174001.3012643-7-jarod@redhat.com> <20201002121317.474c95f0@hermes.local> X-Mailer: Mew version 6.8 on Emacs 27.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [2620:137:e000::1:9]); Fri, 02 Oct 2020 15:36:26 -0700 (PDT) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Stephen Hemminger Date: Fri, 2 Oct 2020 12:13:17 -0700 > On Fri, 2 Oct 2020 13:40:01 -0400 > Jarod Wilson 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.