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]

Message-ID: <040f3d7e-f315-05c1-00a7-f47c4c19eacd@gmail.com>
Date:   Mon, 14 Jan 2019 17:00:07 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>, davem@...emloft.net
Cc:     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 1/14/19 4:50 PM, 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.

I does not seem realistic to expect people to agree on that indeed :)

Took a quick look and this is pretty sensible thanks Jakub!

> 
> 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
> 
> Jakub Kicinski (6):
>   devlink: add device information API
>   devlink: add version reporting API
>   nfp: devlink: report serial number
>   nfp: devlink: report fixed versions
>   nfp: nsp: add support for versions command
>   nfp: devlink: report the running and flashed versions
> 
>  .../net/ethernet/netronome/nfp/nfp_devlink.c  | 154 +++++++++++++++
>  .../ethernet/netronome/nfp/nfpcore/nfp_nsp.c  |  53 ++++++
>  .../ethernet/netronome/nfp/nfpcore/nfp_nsp.h  |  14 ++
>  include/net/devlink.h                         |  15 ++
>  include/uapi/linux/devlink.h                  |  10 +
>  net/core/devlink.c                            | 177 ++++++++++++++++++
>  6 files changed, 423 insertions(+)
> 


-- 
Florian