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] [day] [month] [year] [list]

Message-ID: <B0791B4B-26AD-4A48-8575-54C632CC2FFA@gmail.com>
Date:   Wed, 16 Jan 2019 11:00:14 -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 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