Re: [PATCH] ethtool: ETHTOOL_SFEATURES: remove NETIF_F_COMPAT return

[Ben Hutchings <bhutchings@solarflare.com>]

On Fri, 2011-05-27 at 18:34 +0200, Michał Mirosław wrote:
> On Fri, May 27, 2011 at 04:45:50PM +0100, Ben Hutchings wrote:
> > On Fri, 2011-05-27 at 17:28 +0200, Michał Mirosław wrote:
[...]
> > >      (note: ETHTOOL_S{SG,...} are not ever going away)
> > >    - causes NETIF_F_* to be an ABI
> > If feature flag numbers are not stable then what is the point of
> > /sys/class/net/<name>/features?  Also, I'm not aware that features have
> > ever been renumbered in the past.
> 
> Since no NETIF_F_* were exported earlier, I assume /sys/class/net/*/features
> is a debugging aid. What is it used for besides that?

xen-api <https://github.com/xen-org/xen-api> uses it in
scripts/InterfaceReconfigureVswitch.py.  Though it doesn't seem to be
used for a particularly good reason...

> [...]
> > > Both versions are rough at the edges, but working. Both assume that no
> > > behaviour changes are to be made for old '-K' options.
> > No, my changes are intended to enhance the old options.
> 
> Kernel side already enhances them to not forget other features
> 'wanted' state. What other enhancements are on your mind?

So it does; for some reason I didn't realise that.  Then I suppose there
isn't a benefit from using ETHTOOL_SFEATURES for existing feature flags.

> BTW, I just recalled that ETHTOOL_F_WISH is set only as an information
> about bits in features[].valid masks. So zero return does not mean, that
> other features (not in .valid masks) haven't changed.

That was already true.

> This means that
> userspace needs to reread features after any SFEATURES call, not just
> those returning non-zero.

Not necessarily, though of course it is helpful to report consequential
feature changes.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.