Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3477948pxk; Mon, 5 Oct 2020 10:38:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzDfj8caNW1wcQaHEnStWcnrVzOzmT2L246uU/8o4bGeRbIkwa/Wi5VEPqvEkkcQ1ur2DOx X-Received: by 2002:a17:906:7785:: with SMTP id s5mr779310ejm.345.1601919513942; Mon, 05 Oct 2020 10:38:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601919513; cv=none; d=google.com; s=arc-20160816; b=0Ob+gcrZxKWyE5jDy4h9BSINLgR0KAZHS4FqUih7oIzKQsnCffX6fJmJJqBOjdHrrY snr/U6aHRSa/Jrrx0yc/nxIVYQ4ZTlfkL7KfBIhPsKIyuwyMyR0BHJa4JXQoCQ+DK3fB oGgEGnzXuaDogEaS6EXmNAZ6W+sw6NyEczYPKYff1wyURE6WClH9mhKMcBir/VTuKnpm TdfQO5xySITAS8lYVlaK2euGPXLJWbK32ECgap++eJ9J1hewAEKRInSiqpvL+1zRaciO H3TPy4pr4aOBZKyrsWfBRVn/F0Avmj3TC0pl1soWSzJcHed6ZVUM3JWdSQsI6xoyxgsu a7Mg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:content-id:mime-version:comments :references:in-reply-to:subject:cc:to:from; bh=HrSyF9kLbAGpqzd7NymS9oG0tTI5vKB3qF2XRvywrzs=; b=CrhXFifl62whYQDFxbmi4sMOVoyZtvt6fBB6oErzUUR29fT2jo9XaCbZjnCWblMQfq HZ6/QGN0GXM8XdQx92vPaYoZb/izM75JaxfIvKVPrtgYtnTPF5Mn58zqhdRwTx9vPj/4 c2N6R8g1xu5+6eTMDaEaKQ17vl3islYW5O2/SGzxSYCSLArnxCmgaF90uXwXg6UGslnL 80kjeNC/BiJW8ebO91XlR7fCiu/Ue5BHHWZkx15w7qVHtF1dc72Npk5N09Zbb+xvufkA YS1ZWNOWcjiZdf7TVFqvx0Pd0IoenJMLnCIJYeLxr/5LnwXxVPC1d1+KcUwb6i7ppTX6 APFg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i13si375411edq.350.2020.10.05.10.38.09; Mon, 05 Oct 2020 10:38:33 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728233AbgJERgg (ORCPT + 99 others); Mon, 5 Oct 2020 13:36:36 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:47834 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727344AbgJERgg (ORCPT ); Mon, 5 Oct 2020 13:36:36 -0400 Received: from 1.general.jvosburgh.us.vpn ([10.172.68.206] helo=famine.localdomain) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kPUPT-0002Z5-LX; Mon, 05 Oct 2020 17:36:27 +0000 Received: by famine.localdomain (Postfix, from userid 1000) id 089435FEE7; Mon, 5 Oct 2020 10:36:26 -0700 (PDT) Received: from famine (localhost [127.0.0.1]) by famine.localdomain (Postfix) with ESMTP id 015479FB5C; Mon, 5 Oct 2020 10:36:25 -0700 (PDT) From: Jay Vosburgh To: Jarod Wilson cc: David Miller , Stephen Hemminger , LKML , Veaceslav Falico , Andy Gospodarek , Jakub Kicinski , Thomas Davis , Netdev Subject: Re: [PATCH net-next v2 6/6] bonding: make Kconfig toggle to disable legacy interfaces In-reply-to: References: <20201002174001.3012643-7-jarod@redhat.com> <20201002121317.474c95f0@hermes.local> <20201002.155718.1670574240166749204.davem@davemloft.net> Comments: In-reply-to Jarod Wilson message dated "Sat, 03 Oct 2020 15:48:26 -0400." X-Mailer: MH-E 8.6+git; nmh 1.6; GNU Emacs 27.0.50 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15655.1601919385.1@famine> Date: Mon, 05 Oct 2020 10:36:25 -0700 Message-ID: <15656.1601919385@famine> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jarod Wilson wrote: >On Fri, Oct 2, 2020 at 6:57 PM David Miller wrote: >> >> From: Jarod Wilson >> Date: Fri, 2 Oct 2020 16:23:46 -0400 >> >> > I'd had a bit of feedback that people would rather see both, and be >> > able to toggle off the old ones, rather than only having one or the >> > other, depending on the toggle, so I thought I'd give this a try. I >> > kind of liked the one or the other route, but I see the problems with >> > that too. >> >> Please keep everything for the entire deprecation period, unconditionally. > >Okay, so 100% drop the Kconfig flag patch, but duplicate sysfs >interface names are acceptable, correct? Then what about the procfs >file having duplicate Slave and Port lines? Just leave them all as >Slave? My preference is to not alter the existing sysfs / proc behavior at all, and instead create a netlink / iproute UAPI that becomes the "preferred" UAPI going forward. Any new functionality would only be added to netlink as incentive to switch. I don't see the value in adding duplicate fields, as userspace code that parses them will not be portable if it only checks for the new field name. Then, down the road, deleting the old names will break the userspace code that was never updated (which will likely be most of it). I would rather see a single clean break from proc and sysfs to netlink in one step than a piecemeal addition and removal from the existing UAPI. That makes for a much clearer flag day event for end users. By this I mean leave proc / sysfs as-is today, and then after a suitable deprecation period, remove it wholesale (rather than a compile time option). -J --- -Jay Vosburgh, jay.vosburgh@canonical.com