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:

quoted

On Fri, 2011-05-27 at 17:28 +0200, Michał Mirosław wrote:

[...]

quoted

quoted

     (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...

[...]

quoted

quoted

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.