On Mon, May 13, 2013 at 3:12 PM, Jesse Gross <je...@nicira.com> wrote: > On Mon, May 13, 2013 at 2:28 PM, Pravin Shelar <pshe...@nicira.com> wrote: >> On Mon, May 13, 2013 at 2:19 PM, Jesse Gross <je...@nicira.com> wrote: >>> On Mon, May 13, 2013 at 2:07 PM, Pravin B Shelar <pshe...@nicira.com> wrote: >>>> diff --git a/datapath/linux/compat/include/linux/types.h >>>> b/datapath/linux/compat/include/linux/types.h >>>> index b989d96..4b953f2 100644 >>>> --- a/datapath/linux/compat/include/linux/types.h >>>> +++ b/datapath/linux/compat/include/linux/types.h >>>> @@ -1,12 +1,15 @@ >>>> #ifndef __LINUX_TYPES_WRAPPER_H >>>> #define __LINUX_TYPES_WRAPPER_H 1 >>>> >>>> +#include <linux/version.h> >>>> #include_next <linux/types.h> >>>> >>>> +#if LINUX_VERSION_CODE < KERNEL_VERSION(3,7,0) >>>> #ifndef HAVE_CSUM_TYPES >>>> typedef __u16 __bitwise __sum16; >>>> typedef __u32 __bitwise __wsum; >>>> #endif >>>> +#endif >>> >>> Why isn't this picked up by the configure check? >> because definition is moved to KSRC/include/uapi/linux/types.h. >> >> I had this change as part of patch - "datapath: Integration with >> upstream kernel tunneling" where I updated config script, But you >> suggested to use version check. Am I missing something? >> >> ref:http://openvswitch.org/pipermail/dev/2013-April/026400.html > > I see what happened: I was actually just asking if these functions had > been backported since if they are not then we usually just add a > version check. However, I didn't realize that in this case it was > simply a check in an additional location for functions that were > already known to be backported (in RHEL). Therefore, I think in this > case your original version is the best way to do it. > > I also looked to see if it is likely that we will have a lot of > duplicate checks for uapi and non-uapi locations. It looks like this > is the only one at the moment and is probably likely to mostly stay > that way since it's the internal kernel APIs that have the highest > rate of change. However, if this keeps on coming up then we should > think about extending our macros to automatically check both.
Thanks, I sent out updated patch. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
