Re: [net-next v2 6/8] ixgbe: add syfs interface for to export read only driver information

On 05/01/2012 07:02 AM, David Miller wrote:

From: Jeff Kirsher<redacted>
Date: Tue,  1 May 2012 01:51:07 -0700

quoted

From: Don Skidmore<redacted>

This patch exports non-thermal (which was done via hwmon in an earlier
patch) data to sysfs which isn't readily available elsewhere.  All of the
fields are read only as this interface is to only export driver data.

Signed-off-by: Don Skidmore<redacted>
Tested-by: Stephen Ko<redacted>
Signed-off-by: Jeff Kirsher<redacted>

I don't like it.

Some of this stuff is generic and belongs somewhere like ethtool, for
example the descriptor sizes and queue sizes.

The others are reading registers, and we have an ethtool API for that
already.

But putting anything like this in sysfs is pointless, because the
stuff that other cards have too will then go into differently named
sysfs files which, as is oft repeated here, is a terrible user
experience.

If you want to do this right, add a new ethtool interface that allows
the publication of card specific unchanging values, in a style like
what we already do for statistics.  Have one query that gets the
string list, and then another which fetches the actual values.

And if you decide to go forward with this, I have some ideas for API
and would like to discuss it.  Or, if I beat you to it, I'll post some
RFC patches when I get a chance to write them up.

Basically, I'm thinking of a get-strings(flags), get-types(flags), and get-values(flags)
API.  The types would return an array of enums that would define the data
type, like uint32, int8, etc.  Strings would be same as it is today,
just with a new type.  Values would return array of uint64 as it does now.

To each method you could specify a uint32 flags that would be device specific.
I would like to use flags in wifi to specify whether to get the underlying NIC
stats v/s just the soft-device stats, for instance.  And maybe some additional
granularity if some stats are more costly to get than others so that one could
probe expensive stats more rarely....

And while strings would still be free-form, we could at least attempt to use
the same strings for the same kinds of stats where possible.

Thanks,
Ben


-- 
Ben Greear [off-list ref]
Candela Technologies Inc  http://www.candelatech.com