[ovs-dev] [PATCH] datapath: Fix compilation with linux kernel 3.7.

[Jesse Gross]

On Mon, May 13, 2013 at 2:28 PM, Pravin Shelar <pshelar at nicira.com> wrote:
> On Mon, May 13, 2013 at 2:19 PM, Jesse Gross <jesse at nicira.com> wrote:
>> On Mon, May 13, 2013 at 2:07 PM, Pravin B Shelar <pshelar at 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.