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, 9 Jul 2019 12:06:58 -0700
From:   Shannon Nelson <snelson@...sando.io>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH v3 net-next 19/19] ionic: Add basic devlink interface

On 7/8/19 6:26 PM, Jakub Kicinski wrote:
> On Mon,  8 Jul 2019 12:25:32 -0700, Shannon Nelson wrote:
>> Add a devlink interface for access to information that isn't
>> normally available through ethtool or the iplink interface.
>>
>> Example:
>> 	$ ./devlink -j -p dev info pci/0000:b6:00.0
>> 	{
>> 	    "info": {
>> 		"pci/0000:b6:00.0": {
>> 		    "driver": "ionic",
>> 		    "serial_number": "FLM18420073",
>> 		    "versions": {
>> 			"fixed": {
>> 			    "fw_version": "0.11.0-50",
> Hm. Fixed is for hardware components. Seeing FW version reported as
> fixed seems counter intuitive.  You probably want "running"?

Sure.

>
>> 			    "fw_status": "0x1",
> I don't think this is the right interface to report status-like
> information.  Perhaps devlink health reporters?
>
>> 			    "fw_heartbeat": "0x716ce",
> Ditto, perhaps best to report it in health stuff?

I haven't dug too far into the health stuff, but on the surface it looks 
like a lot of infrastructure for a couple of simple values. I'm tempted 
to put them back into debugfs for the moment rather than add that much 
more interface goo.

>
>> 			    "asic_type": "0x0",
>> 			    "asic_rev": "0x0"
> These seem like legit "fixed" versions 👍
>
>> 			}
>> 		    }
>> 		}
>> 	    }
>> 	}
>>
>> Signed-off-by: Shannon Nelson <snelson@...sando.io>
> Isn't this a new patch? Perhaps you'd be best off upstreaming the
> first batch of support and add features later? It'd be easier on
> reviewers so we don't have to keep re-checking the first 16 patches..

Yes, and I commented about this in v2 notes: in the tension between 
trying to address comments, keep the line count down, keep the basic 
feature set, and keep the patches self-consistent and simple, I added 
this one patch for the devlink goodies that were requested. At least the 
total line count went down.

sln


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ