[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTi=-M=NusYU0U66cbvYeu=560U+xXQ@mail.gmail.com>
Date: Tue, 7 Jun 2011 23:55:10 -0700
From: Mahesh Bandewar <maheshb@...gle.com>
To: David Miller <davem@...emloft.net>
Cc: mst@...hat.com, linux-netdev <netdev@...r.kernel.org>,
Tom Herbert <therbert@...gle.com>,
Michał Mirosław <mirqus@...il.com>,
Stephen Hemminger <shemminger@...tta.com>
Subject: Re: [PATCHv3] net: Define enum for the bits used in features.
On Mon, Jun 6, 2011 at 12:20 PM, David Miller <davem@...emloft.net> wrote:
> From: "Michael S. Tsirkin" <mst@...hat.com>
> Date: Mon, 6 Jun 2011 18:32:53 +0300
>
>> On Sun, Jun 05, 2011 at 10:15:37PM -0700, David Miller wrote:
>>> Since the GSO accessors deal with mutliple bits, you can create
>>> special GSO specific interfaces to manipulate them.
>>
>> Yes but it's not just GSO.
>> It's anything that includes more than 1 feature.
>> Examples:
>> NETIF_F_ALL_CSUM
>> NETIF_F_ALL_TX_OFFLOADS
>> NETIF_F_V6_CSUM
>> NETIF_F_SOFT_FEATURES
>>
>> etc
>>
>> Creating many accessors for each will need a lot
>> of code duplication ...
>
> Yet this is something you must resolve in order to change the feature
> bit implementation.
>
> Whether this issue is difficult or not to address, it has to be done
> either way.
>
I agree that the cleanup is not really necessary to the feature
extension as such but this along with the other patch that I have
posted is the beginning of that work. It's definitely not complete and
also not as simple as it sounds / feels because of these constants
defined which are "or-ed" flag values (listed above). I think it will
be nice to get this done in as little code as possible, but I think
that should be the constraint.
In these two patches I have created separate header file
"netdev_features.h" where everything related to "features" should
reside including all these accessor macros / functions.
--mahesh..
--
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