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

[Pravin Shelar]

On Mon, May 13, 2013 at 3:12 PM, Jesse Gross <jesse at nicira.com> wrote:
> 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.

Thanks,
I sent out updated patch.