[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220811081311.0f549b39@kernel.org>
Date: Thu, 11 Aug 2022 08:13:11 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Alexander Lobakin <alexandr.lobakin@...el.com>
Cc: "shenjian (K)" <shenjian15@...wei.com>, davem@...emloft.net,
andrew@...n.ch, ecree.xilinx@...il.com, hkallweit1@...il.com,
saeed@...nel.org, leon@...nel.org, netdev@...r.kernel.org,
linuxarm@...neuler.org
Subject: Re: [RFCv7 PATCH net-next 36/36] net: redefine the prototype of
netdev_features_t
On Thu, 11 Aug 2022 15:07:57 +0200 Alexander Lobakin wrote:
> > Yes, Jakub also mentioned this.
> >
> > But there are many existed features interfaces(e.g. ndo_fix_features,
> > ndo_features_check), use netdev_features_t as return value. Then we
> > have to change their prototype.
>
> We have to do 12k lines of changes already :D
> You know, 16 bytes is probably fine to return directly and it will
> be enough for up to 128 features (+64 more comparing to the
> mainline). OTOH, using pointers removes that "what if/when", so
> it's more flexible in that term. So that's why I asked for other
> folks' opinions -- 2 PoVs doesn't seem enough here.
From a quick grep it seems like the and() is mostly used in some form
of:
features = and(features, mask);
and we already have netdev_features_clear() which modifies its first
argument. I'd also have and() update its first arg rather than return
the result as a value. It will require changing the prototype of
ndo_features_check() :( But yeah, I reckon we shouldn't be putting of
refactoring, best if we make all the changes at once than have to
revisit this once the flags grow again and return by value starts to
be a problem.
Powered by blists - more mailing lists