On 04/12/2012 12:30 PM, Ben Hutchings wrote:
On Thu, 2012-04-12 at 09:51 -0700, Ben Greear wrote:
On 04/12/2012 09:42 AM, Florian Fainelli wrote:
Hi,
Le 04/12/12 18:32, greearb@xxxxxxxxxxxxxxx a écrit :
From: Ben Greear<greearb@xxxxxxxxxxxxxxx>
The signal and noise are forced to be positive since ethtool
deals in unsigned 64-bit values and this number should be human
readable. This gives easy access to some of the data formerly
exposed in the deprecated /proc/net/wireless file.
Uh, that's misleading, the signal and noise values are typically negative, so one needs to think about mentally adding a minus sign if he/she wants to
understand it. Does not ethtool know about 32-bits signed integers?
Ethtool stats only supports u64. I think it's easy enough for
humans or programs to add the negative sign. Can signal or noise
ever be> 0? If so, that could actually break something that depends
on flipping the value to negative....
So far as I can see, the ethtool stats were expected to be counters,
which obviously cannot become negative (or fractional). Maybe it's time
to define another command and string-set to cover other types of status
information. The ethtool utility could ask for those typed statistics
as well, so 'ethtool -S' would get all of them.
One nice thing about ethtool stats API is that it is backwards and forwards
compatible for a long while. Also, adding a new API means a second call
into the kernel (most likely) for the other set of strings, which effectively
doubles the cost of getting stats (and allows the stats to be updated
out-of-sync with each other more easily).
I wonder if instead we could add a convention where we add a short
prefix (or suffix) to a string to denote it's type (and cast the value
into u64). So, an old ethtool might see:
foo:s32: 4294967295
while a new one understand that the s32: prefix is special, do
some casting, and could show:
foo: -1
Both are still at least somewhat human readable, and probably wouldn't
confuse anyone that is parsing the output of existing ethtool output.
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
