[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7B7B83D2-5F56-4E7D-A313-4F8E48B23119@gmail.com>
Date: Tue, 15 Jan 2019 11:30:10 -0800
From: "Jonathan Lemon" <jonathan.lemon@...il.com>
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 14 Jan 2019, at 16:50, 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.
>
> Since the driver information pertains to the entire device, rather
> than a particular netdev, it seems wise to move it do devlink, at
> the same time fixing the aforementioned issues.
>
> The new API allows exposing the device serial number and versions
> of the components of the card - both hardware, firmware (running
> and flashed). Driver authors can choose descriptive identifiers
> for the version fields. There is a potential for defining common
> fields here, but given the general direction of the stack I don't
> think people would like that.
>
> Example:
> $ devlink info show
> pci/0000:05:00.0:
> serial_number: 00:15:4d:12:20:7e
> versions:
> fixed:
> board.model carbon
> board.partno AMDA0099-0001
> board.revision 07
> board.vendor SMA
> running:
> fw.mgmt: 010156.010156.010156
> fw.cpld: 0x44
> fw.app: sriov-2.1.16
> stored:
> fw.mgmt: 010158.010158.010158
> fw.cpld: 0x44
> fw.app: sriov-2.1.20
How about adding the driver name and version as well?
When connecting to an unknown system, "ethtool -i" is useful in
discovering what is actually running.
--
Jonathan
Powered by blists - more mailing lists