On Mon, 2014-05-19 at 09:36 +0200, Bjørn Mork wrote: > 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... [...] By the way, ethtool can now be configured without pretty-printing of register/EEPROM dumps. This reduces it in size from ~240K to ~60K. If that's still not small enough, the answer might be to put a limited reimplementation of ethtool in busybox, toybox or similar. Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity.
Attachment:
signature.asc
Description: This is a digitally signed message part
