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

Powered by Openwall GNU/*/Linux Powered by OpenVZ