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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ