[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191010174839.6e44158b@cakuba.netronome.com>
Date: Thu, 10 Oct 2019 17:48:39 -0700
From: Jakub Kicinski <jakub.kicinski@...ronome.com>
To: 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>,
Johannes Berg <johannes@...solutions.net>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v7 00/17] ethtool netlink interface, part 1
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)?
Powered by blists - more mailing lists