Re: inconsistency of ethtool feature names for get vs. set

[Bill Fink <billfink@mindspring.com>]

On Thu, 2 Jan 2014, Ben Hutchings wrote:

> On Thu, 2014-01-02 at 15:03 +0000, Ben Hutchings wrote:
> > On Thu, 2014-01-02 at 11:47 +0200, Or Gerlitz wrote:
> [...]
> > > $ ethtool -k eth1  | grep generic-receive-offload
> > > generic-receive-offload: on
> > > 
> > > $ ethtool -K eth1  generic-receive-offload off
> > > ethtool: bad command line argument(s)
> > > For more information run ethtool -h
> > > 
> > > --> looking in the sources and realizing I need to use "rx-gro"
> > 
> > Or 'gro'.  All the old feature names that can be used with the -K option
> > are listed in the manual page.  All the new feature names are consistent
> > between -k/-K.
> 
> By 'new feature names' I mean names for features that weren't previously
> exposed through ethtool.
> 
> [...]
> > > Basically, this can be resolved by fairly simple patch, but I wasn't 
> > > sure if you want it in user space, in the kernel or both...
> > 
> > How do you intend to resolve this, given the compatibility requirement
> > that the old names must still be reported by -k and accepted by -K?
> 
> Just to be clear, I do see that there's a problem here but the fix may
> have to be mostly or entirely in documentation rather than code.

Wouldn't one simple option be to allow the long form like
generic-receive-offload for setting in addition to the existing
shortcuts rx-gro and gro?  That way a user doing "ethtool -k"
could use the name provided to do a set via "ethtool -K" without
needing to consult a man page (or "ethtool -h"), while still
allowing more knowledgeable users to use the shortcut names.

					-Bill