[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150826073757.GB2215@nanopsycho.orion>
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