On Thu, Sep 17, 2015 at 1:12 PM, Jesse Gross <je...@nicira.com> wrote:
> On Thu, Sep 17, 2015 at 11:49 AM, Pravin Shelar <pshe...@nicira.com> wrote:
>> On Wed, Sep 16, 2015 at 2:43 PM, Jesse Gross <je...@nicira.com> wrote:
>>> On Tue, Sep 15, 2015 at 11:09 AM, Pravin B Shelar <pshe...@nicira.com>
>>> wrote:
>>>> diff --git a/.travis.yml b/.travis.yml
>>>> index d14f786..f4b9188 100644
>>>> --- a/.travis.yml
>>>> +++ b/.travis.yml
>>>> @@ -12,7 +12,8 @@ env:
>>>> - TESTSUITE=1 KERNEL=3.18.1
>>>> - TESTSUITE=1 OPTS="--enable-shared"
>>>> - BUILD_ENV="-m32" OPTS="--disable-ssl"
>>>> - - KERNEL=4.0.2
>>>> + - KERNEL=4.1.6
>>>> + - KERNEL=4.0.9
>>>
>>> Is there a reason to have both 4.0 and 4.1 tested?
>>>
>> right, I have removed it in next patch.
>
> But then the next patch adds 4.2 and keeps 4.1. I guess the larger
> point is, is there a reason to do test builds on each of these point
> releases or just do we only need the latest one?
>
I just wanted to keep it consistent with kernel versions listed on
kernel.org. Those kernel most likely change and therefore needs to be
compiled for.
>>>> diff --git a/datapath/datapath.h b/datapath/datapath.h
>>>> index 526ddad..aca9407 100644
>>>> --- a/datapath/datapath.h
>>>> +++ b/datapath/datapath.h
>>>> static inline struct net *ovs_dp_get_net(const struct datapath *dp)
>>>> {
>>>> - return read_pnet(&dp->net);
>>>> + return rpl_read_pnet(&dp->net);
>>>> }
>>>>
>>>> static inline void ovs_dp_set_net(struct datapath *dp, struct net *net)
>>>> {
>>>> - write_pnet(&dp->net, net);
>>>> + rpl_write_pnet(&dp->net, net);
>>>> }
>>>
>>> Can we use macros here so we don't need to call the rpl_ versions directly?
>>
>> If I use the macro then it causes compilation issue in older linux
>> header that calls write_pnet(),read_pnet() due to undefined struct
>> possible_net_t. I can move these definitions to compat.h file to make
>> it clear.
>
> OK. In that case, I would just keep it as it is - I'm not sure that it
> makes it clearer to have it in compat.h since it really is a
> backported function. Either way is fine though.
ok. I will keep it as it is.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
