[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dfc9572f853713577e3798b3ff0449483ce274f3.camel@sipsolutions.net>
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