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:   Wed, 16 Jan 2019 00:41:48 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     Jonathan Lemon <jonathan.lemon@...il.com>, davem@...emloft.net,
        netdev@...r.kernel.org, oss-drivers@...ronome.com
Subject: Re: [RFC net-next 0/6] devlink: add device (driver) information API

Tue, Jan 15, 2019 at 10:06:42PM CET, jakub.kicinski@...ronome.com 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

Agreed. I intended to do that for initial devlink implementation.


>the driver version.  In most scenarios kernel version is most reliable.
>It's mostly out-of-tree drivers that need the driver version.

Yep. The "driver version" really makes no sense.