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] [day] [month] [year] [list]

Message-ID: <15656.1601919385@famine>
Date:   Mon, 05 Oct 2020 10:36:25 -0700
From:   Jay Vosburgh <jay.vosburgh@...onical.com>
To:     Jarod Wilson <jarod@...hat.com>
cc:     David Miller <davem@...emloft.net>,
        Stephen Hemminger <stephen@...workplumber.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Veaceslav Falico <vfalico@...il.com>,
        Andy Gospodarek <andy@...yhouse.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Thomas Davis <tadavis@....gov>, Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v2 6/6] bonding: make Kconfig toggle to disable legacy interfaces

Jarod Wilson <jarod@...hat.com> wrote:

>On Fri, Oct 2, 2020 at 6:57 PM David Miller <davem@...emloft.net> wrote:
>>
>> From: Jarod Wilson <jarod@...hat.com>
>> 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@...onical.com