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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
