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] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 11 Oct 2019 08:46:59 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Michal Kubecek <mkubecek@...e.cz>
Cc:     David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
        Jiri Pirko <jiri@...nulli.us>, Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        John Linville <linville@...driver.com>,
        Stephen Hemminger <stephen@...workplumber.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v7 00/17] ethtool netlink interface, part 1

On Thu, 2019-10-10 at 17:48 -0700, Jakub Kicinski wrote:
> On Wed,  9 Oct 2019 22:59:00 +0200 (CEST), Michal Kubecek wrote:
> > This is first part of netlink based alternative userspace interface for
> > ethtool. It aims to address some long known issues with the ioctl
> > interface, mainly lack of extensibility, raciness, limited error reporting
> > and absence of notifications. The goal is to allow userspace ethtool
> > utility to provide all features it currently does but without using the
> > ioctl interface. However, some features provided by ethtool ioctl API will
> > be available through other netlink interfaces (rtnetlink, devlink) if it's
> > more appropriate.
> 
> Looks like perhaps with ETHTOOL_A_HEADER_RFLAGS checking taken out of
> the picture we can proceed as is and potentially work on defining some
> best practices around attrs and nesting for the future generations? :)
> 
> I was trying to find a way to perhaps start merging something.. Would
> it make sense to spin out patches 1, 2, 3, and 8 as they seem to be
> ready (possibly 11, too if the reorder isn't painful)?

I was surprised 3 didn't go in even last time this was posted, it seems
such an obvious thing and not necessary just for ethtool :)

johannes

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ