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

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