Lars Melin <larsm17@xxxxxxxxx> writes: > Your target audience is embedded systems with limited cpu power and > buffer memory, right? > If so, then you can't expect them to have ethtool included and their > developers are not likely to be happy over having to "waste" another > 100KB in order to tune a 20KB driver. > My vote goes for sysfs. That's of course a very good point. I will argue that you often need ethtool anyway for basic stuff like forcing duplex/speed, enabling debug messages, turning on/off pause frames etc. But I don't doubt you know what you are talking about here :-) So I guess many small embedded devices don't include an ethtool binary by default. I do wonder how much we should adapt to that though? I understand that you don't see it this way, but others might actually see it as an advantage if we're forcing ethtool onto these devices... Anyway, I'll start looking at an alternative sysfs implementation so we can discuss this in terms of actual code. But I will definitely leave the statistics in any case, so if you want that then you will need ethtool. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
