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;
MIME-Version: 1.0
References: <20200922133731.33478-1-jarod@redhat.com> <20200922133731.33478-5-jarod@redhat.com>
In-Reply-To: <20200922133731.33478-5-jarod@redhat.com>
From:   Jarod Wilson <jarod@redhat.com>
Date:   Tue, 22 Sep 2020 18:05:00 -0400
Message-ID: <CAKfmpSfv8L46MjYHfUCMcz+Wxed4EpO1FEu8NjqVU6W8_m9E=w@mail.gmail.com>
Subject: Re: [PATCH net-next 4/5] bonding: make Kconfig toggle to disable
 legacy interfaces
To:     LKML <linux-kernel@vger.kernel.org>
Cc:     Jay Vosburgh <j.vosburgh@gmail.com>,
        Veaceslav Falico <vfalico@gmail.com>,
        Andy Gospodarek <andy@greyhouse.net>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Thomas Davis <tadavis@lbl.gov>, Netdev <netdev@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Sep 22, 2020 at 9:38 AM Jarod Wilson <jarod@redhat.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.
> diff --git a/drivers/net/bonding/bond_procfs.c b/drivers/net/bonding/bond_procfs.c
> index abd265d6e975..91ece68607b2 100644
> --- a/drivers/net/bonding/bond_procfs.c
> +++ b/drivers/net/bonding/bond_procfs.c
> @@ -7,6 +7,12 @@
>
>  #include "bonding_priv.h"
>
> +#ifdef CONFIG_BONDING_LEGACY_INTERFACES
> +const char *linkdesc = "Slave";
> +#else
> +const char *linkdesc = "Link";
> +#endif

I've been asked if it would be okay to add extra lines to the
/proc/net/bonding/<bond interface> output, so that for example, both
"Slave Interface: <interface>" and "Link Interface: <interface>" are
both in the default output, with the Slave bits then suppressed by the
Kconfig option being unset, versus the Kconfig option currently
swapping out Slave for Link when disabled. It would bloat the output
by a fair number of lines, but all the same data would be there and
parseable. Wasn't sure on this one, so I wanted to check on it. If it
would be acceptable, I'll rework that bit of code.

-- 
Jarod Wilson
jarod@redhat.com