[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTi=zk6aYCMU-UR+_6eXXDk=nQdZSgQ@mail.gmail.com>
Date: Tue, 24 May 2011 16:25:50 -0700
From: Mahesh Bandewar <maheshb@...gle.com>
To: Stephen Hemminger <shemminger@...tta.com>
Cc: David Miller <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
Tom Herbert <therbert@...gle.com>
Subject: Re: [PATCH] net: Abstract features usage.
On Tue, May 24, 2011 at 4:11 PM, Stephen Hemminger
<shemminger@...tta.com> wrote:
> On Tue, 24 May 2011 16:04:20 -0700
> Mahesh Bandewar <maheshb@...gle.com> wrote:
>
>> On Tue, May 24, 2011 at 2:29 PM, Stephen Hemminger
>> <shemminger@...tta.com> wrote:
>> > On Tue, 24 May 2011 11:52:42 -0700
>> > Mahesh Bandewar <maheshb@...gle.com> wrote:
>> >
>> >> Define macros to set/clear/test bits for feature set usage. This will eliminate
>> >> the direct use of these fields and enable future ease in managing these fields.
>> >>
>> >> Signed-off-by: Mahesh Bandewar <maheshb@...gle.com>
>> >> ---
>> >> include/linux/netdev_features.h | 137 +++++++++++++++++++++++++++++++++++++++
>> >> include/linux/netdevice.h | 35 ++---------
>> >> 2 files changed, 142 insertions(+), 30 deletions(-)
>> >> create mode 100644 include/linux/netdev_features.h
>> >>
>> >> diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
>> >> new file mode 100644
>> >> index 0000000..97bf8c4
>> >> --- /dev/null
>> >> +++ b/include/linux/netdev_features.h
>> >> @@ -0,0 +1,137 @@
>> >> +#ifndef _NETDEV_FEATURES_H
>> >> +#define _NETDEV_FEATURES_H
>> >> +
>> >> +/* Forward declarations */
>> >> +struct net_device;
>> >> +
>> >> +typedef unsigned long *nd_feature_t
>> >
>> > typedef'ing a pointer is strongly discouraged by kernel coding style.
>> > You need to use another way such as open coding it.
>> >
>> The idea here is to have a typedef that we can use to avoid future
>> changes all over the code if we decide to change the way feature bits
>> are stored. So if this is bitmap it will be defined as "unsigned long
>> *" and if it were to be u64 then it's typedef-ed as "u64". So in one
>> case it's a pointer and in other case it's not! Now how do we handle
>> both these cases?
>
> It is okay to add a typedef for a fixed width type.
> Just not adding the indirection
> because it leads to confusion.
>
> Read "Chapter 5: Typedefs" in Documentation/CodingStyle
>
Yes, this usage matches the (a) case in the documentation. This
typedef is to hide the object but enable APIs to pass it around for
reference and it _should_ only be altered by using the helper APIs
from this file. If we find a certain API is missing, it should be
added here instead of doing some local magic.
Thanks,
--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