Re: [PATCH] net: Abstract features usage.

[Stephen Hemminger <shemminger@vyatta.com>]

On Tue, 24 May 2011 16:04:20 -0700
Mahesh Bandewar <maheshb@google.com> wrote:

> On Tue, May 24, 2011 at 2:29 PM, Stephen Hemminger
> <shemminger@vyatta.com> wrote:
> > On Tue, 24 May 2011 11:52:42 -0700
> > Mahesh Bandewar <maheshb@google.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@google.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



--