[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110222170326.GA10540@rere.qmqm.pl>
Date: Tue, 22 Feb 2011 18:03:26 +0100
From: Michał Mirosław <mirq-linux@...e.qmqm.pl>
To: Ben Hutchings <bhutchings@...arflare.com>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH ethtool 2/3] ethtool: Regularise handling of offload
flags
On Tue, Feb 22, 2011 at 04:44:33PM +0000, Ben Hutchings wrote:
> On Tue, 2011-02-22 at 15:50 +0100, Michał Mirosław wrote:
> > On Mon, Feb 21, 2011 at 04:59:08PM +0000, Ben Hutchings wrote:
> > > Use the new ETHTOOL_{G,S}FEATURES operations where available, and
> > > use the new structure and netif feature flags in any case.
> > >
> > > Replace repetitive code for getting/setting offload flags with data-
> > > driven loops.
> > >
> > > This changes error messages to use the same long names for offload
> > > flags as in dump_offload(), and changes various exit codes to 1.
> > >
> > > Signed-off-by: Ben Hutchings <bhutchings@...arflare.com>
> > > ---
> > > NEITF_F_* flags are copied into ethtool-util.h for now. I think in
> > > future they should be exposed from <linux/netdevice.h> (hence the
> > > #ifndef).
> > I tried to avoid making NETIF_F_ flags an ABI. That's why there's new
> > ETH_SS_FEATURES ethtool string set. When bits in features get used up
> > it might be desirable to reorder them while introducing a new field
> > in struct net_device (eg. move non-changeable bits out of features).
> The order is unimportant. And feature flags are already exposed through
> sysfs, so they are part of the kernel ABI.
Since NETIF_F flags are not exposed in the headers I would assume that
/sys/class/net/*/features is a debugging aid and not part of an ABI.
(And I think that's good.)
Best Regards,
Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists