netdev - Re: [RFC net-next 0/6] devlink: add device (driver) information API

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:   Mon, 14 Jan 2019 17:33:06 -0800
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Andrew Lunn <andrew@...n.ch>
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 Tue, 15 Jan 2019 02:18:59 +0100, Andrew Lunn wrote:
> 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.

I think the plan was to use this opportunity to move the information
which belongs in devlink to devlink.  There is absolutely nothing
netdev specific here, and ethtool uses a netdev as a handle.  We can
have the new ethtool command just issue a devlink request behind the
scenes if we care.

There are failure modes in which netdevs are not available because FW
init fails, but the driver can hang onto the device with devlink
active, to allow users to troubleshoot and hopefully one day - flash 
a new FW (flashing is another thing that doesn't belong in ethtool).