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 19:27:34 -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:57:55 +0100, Andrew Lunn wrote:
> > 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.  
> 
> Hi Jakub
> 
> Using that argument, you should probably make the devlink core call
> the ethtool .get_drvinfo op if the device does not implement the
> devlink op.

Could it possibly be done in user space?  Have iproute2/devlink call old
ethtool API on first netdev associated with one of the ports?

What concerns me is that the versions drivers report become de facto
uABI.  Deployment scripts all over the place may be using bits of
information contained in there.  If we start reporting .get_drvinfo as,
let's say, field "ethtool.fw_version" or "legacy.fw_version" of devlink
output we may have to _always_ report it.  We can't make it disappear
once the driver decides to break down the info in more detail.

We also don't really know whether ethool.fw_version is fixed, flashed
or running version.

Hm..

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ