[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190115011859.GA8882@lunn.ch>
Date: Tue, 15 Jan 2019 02:18:59 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org,
oss-drivers@...ronome.com, jiri@...nulli.us
Subject: Re: [RFC net-next 0/6] devlink: add device (driver) information API
On Mon, Jan 14, 2019 at 04:50:02PM -0800, Jakub Kicinski wrote:
> Hi!
>
> For quite some time now the ethtool -i API has been showing its age.
> The driver version field is generally considered obsolete these
> days, and driver authors are encouraged to report the kernel version.
> fw_version field does not suit modern needs with 31 characters being
> quite limiting on more complex systems. There is also no distinction
> between the running and flashed versions of the firmware.
Hi Jakub
I agree with what you are saying. However, the ethtool API is not
going to go away anyway soon. By introducing a second place to look
for version information, we are just going to confuse users.
There is an effort going on to replace the basic ethtool kAPI with a
netlink socket. That opens up the possibility to return additional
information. We can avoid the two places to look. Just tell your users
to use the netlink version of ethtool and they can get additional
version information.
I can understand using devlink where there is no existing API, but
when we do have an API, we should try to avoid duplicating it in a new
tool, just to extend it.
Andrew
Powered by blists - more mailing lists