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
| ||
|
Date: Tue, 12 Apr 2022 10:16:26 +0200 From: Jiri Pirko <jiri@...nulli.us> To: Jakub Kicinski <kuba@...nel.org> Cc: Michael Guralnik <michaelgur@...dia.com>, netdev@...r.kernel.org, jiri@...dia.com, ariela@...dia.com, maorg@...dia.com, saeedm@...dia.com, moshe@...dia.com Subject: Re: [RFC PATCH net-next 0/2] devlink: Add port stats Mon, Apr 11, 2022 at 08:01:57PM CEST, kuba@...nel.org wrote: >On Mon, 11 Apr 2022 12:31:53 +0200 Jiri Pirko wrote: >> Fri, Apr 08, 2022 at 05:16:38AM CEST, kuba@...nel.org wrote: >> >On Thu, 7 Apr 2022 11:40:48 +0300 Michael Guralnik wrote: >> >> This patch set adds port statistics to the devlink port object. >> >> It allows device drivers to dynamically attach and detach counters from a >> >> devlink port object. >> > >> >The challenge in defining APIs for stats is not in how to wrap a free >> >form string in a netlink message but how do define values that have >> >clear semantics and are of value to the user. >> >> Wait, does all stats have to be well-defined? I mean, look at the >> ethtool stats. They are free-form strings too. Do you mean that in >> devlink, we can only have well-defines enum-based stats? > >That's my strong preference, yes. > >First, and obvious argument is that it make lazy coding less likely >(see devlink params). > >More importantly, tho, if your stats are not well defined - users don't >need to seem them. Really! If I can't draw a line between a statistic >and device behavior then keep that stat in the register dump, debugfs During the DaveM's-only era, there was quite strict policy against any debugfs usage. As far as I remember the claim was, find of define the proper api or do your debug things out-of-tree. Does that changed? I just want to make sure that we are now free to use debugfs for exposuse of debugging info as "odd vendor stats". Personally, I think it is good idea. I think that the rest of the kernel actually uses debugfs like that. Thanks! >or /dev/null. > >That's why it's important that we talk about _what_ you're trying to >expose. Basically a mixture of quite generic things and very obscure device specific items.
Powered by blists - more mailing lists