On 15 Jan 2019, at 13:06, Jakub Kicinski wrote:
> On Tue, 15 Jan 2019 11:30:10 -0800, Jonathan Lemon wrote:
>> 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.
>
> I'm happy to add the driver name, I'd, however, rather steer clear of
> the driver version. In most scenarios kernel version is most reliable.
> It's mostly out-of-tree drivers that need the driver version.
The driver name + kernel version will work just fine as well.
Thanks!
--
Jonathan
