On 03/16/2012 07:59 AM, Florian Fainelli wrote:
Le 03/16/12 15:54, Ben Greear a écrit :
Ethtool provides what it provides. If it's missing a stat, I or someone else can add it.
What if we don't want to bloat ethtool with new stats? I mean, someone else one day will see wireless stats in, and say, hey why don't I add atm, x25, or any
protocol of the moment to ethtool, then what do we do?
Cheer and be happy! Or, make the code conditionally compiled
if you are very scarce on RAM.
And if it's not there, then users can do without or get it elsewhere.
iw does not provide any way to get underlying wifi radio counters, and
the only other way I've found is to parse various debugfs files that
are subject to change at a whim.
That's another topic, if debugfs interface changes you should complain to their maintainers.
Ethtool is a step up from that at least.
iw is also not supposed to be screen-scraped, while ethtool stats are a
fairly easily parsed output so scripts and such could use that.
Why not fix iw instead so its output gets nicely parsed?
debugfs and iw output is meant to be parsed by humans.
In particular, debugfs is not a 'real' api and can change
all the time.
Would there be no reporting tool that I would not object, otherwise I prefer to keep things where they are consistent, that is, iw configures and reports stats
for wireless, and so does ethtool for Ethernet interfaces.
Another problem with using iw: You have to modify user-space as well
as the kernel to get new stats. But, with ethtool, you can just modify
the kernel and any remotely modern ethtool executable can display
the new stats.
Note that my patches require NO changes to the ethtool binary to display
the new stats.
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
