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, 26 Aug 2015 09:37:57 +0200
From:	Jiri Pirko <jiri@...nulli.us>
To:	David Miller <davem@...emloft.net>
Cc:	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

Wed, Aug 26, 2015 at 08:08:21AM CEST, davem@...emloft.net wrote:
>From: Jiri Pirko <jiri@...nulli.us>
>Date: Wed, 26 Aug 2015 07:52:15 +0200
>
>> They are simple statistics. But they does not fit into any existing
>> interface. This is about EMAD packets. They are not per-netdevice, but
>> per-pcidevice. So I cannot put them into ethtool.
>> 
>> I see no other iface to expose this other than debugfs. Please suggest
>> some other way, I don't see it :/
>
>Then create one, instead of crapping up the driver with debugfs
>craziness.

I'm not sure it is possible to come up with a generic interface for
arbitraty statistics for some generic PCI device.

I can imagine the pushback saying "hey, put that statistics into subtree
specific area, like netdev etc". And that is correct. In vast majority
of cases, that can be done.

In mlxsw case however, 36 netdevices are sharing 1 pci device. And the
stuff related to that pci device cannot be exposed via netdev.

I don't think that are much more cases like this. Therefore I think that
for this cases, debugfs might be a good way to expose debugging stats.


>
>>>I'm not applying this, and I'm really getting irritated about how much
>>>garbage people put into debugfs when it has _NO_ business being there.
>> 
>> I think that is the primary purpose of this iface, To put arbitrary
>> debugging garbage there. Am I missing something?
>
>It's not garbage if it's useful for someone.
>
>If it's not useful, why even bother?
>
>This is why I hate debugfs, it's a fundamentally flawed facility.
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ