netdev - Re: [patch net-next 2/3] mlxsw: expose EMAD transactions statistics via debugfs

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] [day] [month] [year] [list]

Message-ID: <20150916131424.GA2311@localhost.localdomain>
Date:	Wed, 16 Sep 2015 10:14:25 -0300
From:	Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To:	Jiri Pirko <jiri@...nulli.us>
Cc:	David Miller <davem@...emloft.net>, sfeldma@...il.com,
	netdev@...r.kernel.org, idosch@...lanox.com, eladr@...lanox.com,
	ogerlitz@...lanox.com, jiri@...lanox.com
Subject: Re: [patch net-next 2/3] mlxsw: expose EMAD transactions statistics
 via debugfs

On Thu, Aug 27, 2015 at 08:40:29AM +0200, Jiri Pirko wrote:
> Thu, Aug 27, 2015 at 08:36:03AM CEST, davem@...emloft.net wrote:
> >From: Jiri Pirko <jiri@...nulli.us>
> >Date: Thu, 27 Aug 2015 08:27:04 +0200
> >
> >> I'm not saying it is not possible, it certainly is. But I think that
> >> for example rocker internals have no value to default user, he
> >> should not care and he cannot find out what is going on there
> >> without knowledge or rocker.c code. The question is, do we need some
> >> standard interface to expose random debugging data? I don't think
> >> so, I think that debugfs is exactly the tool to be used in that
> >> case.
> >
> >If it is only interesting to rocker.c maintainer, he can keep a local
> >patch he applies when he needs such a facility.
> >
> >This discussion is becomming circular.
> >
> >If it's useful, it needs a well defined interface.
> >
> >If it's not useful, it doesn't belong in the tree.
> >
> >Therefore, debugfs is useless.
> 
> Fair enough.

Late reply, sorry, but another idea is to leave the stats in place (as
they were going to be calculated even with debugfs unmounted) and (for
now at least) fetch them with systemtap, perf or something like that.
Then the stats are there for when you need them and with an interface as
flexible as it can get. Even if you happen to do a post-mortem analysis,
the info would at least be there.

  Marcelo

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html