Re: [RFCv3 PATCH net-next] net: extend netdev_features_t

quoted

quoted

  static int hns3_alloc_buffer(struct hns3_enet_ring *ring,

diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
index 16f778887e14..9b3ab11e19c8 100644
--- a/include/linux/netdev_features.h
+++ b/include/linux/netdev_features.h

@@ -101,12 +101,12 @@ enum {
  typedef struct {
  	DECLARE_BITMAP(bits, NETDEV_FEATURE_COUNT);
-} netdev_features_t;
+} netdev_features_t;

quoted

That hunk looks odd.

Yes, but it can be return directly, so we don't have to change
the prototype of functions which return netdev_features_t,
like  ndo_features_check.

quoted

quoted

-static inline void netdev_feature_zero(netdev_features_t *dst)
+static inline void netdev_features_zero(netdev_features_t *dst)
  {
  	bitmap_zero(dst->bits, NETDEV_FEATURE_COUNT);
  }
-static inline void netdev_feature_fill(netdev_features_t *dst)
+static inline void netdev_features_fill(netdev_features_t *dst)
  {
  	bitmap_fill(dst->bits, NETDEV_FEATURE_COUNT);
  }

I'm wondering that the value here is? What do we gain by added the s.
These changes cause a lot of churn in the users of these functions.

This function is used to expression like below:

"lowerdev_features &= (features | ~NETIF_F_LRO);"  in drivers/net/macvlan.c

O.K, now i know what is confusing me. This is not a patch on top of
clean net-next/master. It does not have netdev_features_t as a bitmap,
it does not have netdev_feature_fill().

You already have some other changes applied to your tree, and this
patch is on top of that?

I think we generally agree about the direction you are going. What we
probably want to see is a patchset against net-next/master which
converts the core and one driver to this new API. That allows us to
review the new API, which is the important thing here.

 I prefered to rename the netdev field active_features .

O.K.

	Andrew