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: <20190115130642.0113288e@cakuba.netronome.com>
Date:   Tue, 15 Jan 2019 13:06:42 -0800
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     "Jonathan Lemon" <jonathan.lemon@...il.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 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.