[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190114192734.47c25589@cakuba.netronome.com>
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