[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1402264922.23860.37.camel@deadeye.wl.decadent.org.uk>
Date: Sun, 08 Jun 2014 23:02:02 +0100
From: Ben Hutchings <ben@...adent.org.uk>
To: Bjørn Mork <bjorn@...k.no>
Cc: Lars Melin <larsm17@...il.com>, Peter Stuge <peter@...ge.se>,
Enrico Mioso <mrkiko.rs@...il.com>,
David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
linux-usb@...r.kernel.org, alexey.orishko@...il.com,
oliver@...kum.org, David.Laight@...lab.com
Subject: Re: [PATCH net-next v2 00/12] cdc_ncm: add buffer tuning and stats
using ethtool
On Mon, 2014-05-19 at 09:36 +0200, Bjørn Mork wrote:
> Lars Melin <larsm17@...il.com> 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.
Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)
Powered by blists - more mailing lists