On 3/30/22 22:36, Gregory Rose wrote:
> 
> 
> On 3/21/2022 3:18 AM, Ilya Maximets wrote:
>> On 1/6/21 20:42, Ilya Maximets wrote:
>>> On 1/6/21 8:09 PM, Gregory Rose wrote:
>>>>
>>>>
>>>> On 1/6/2021 10:55 AM, Ilya Maximets wrote:
>>>>> On 1/6/21 7:09 PM, Gregory Rose wrote:
>>>>>>
>>>>>>
>>>>>> On 1/6/2021 4:34 AM, Ilya Maximets wrote:
>>>>>>> On 1/5/21 7:33 PM, Greg Rose wrote:
>>>>>>>> As agreed in (1) deprecate the Linux OOT driver.
>>>>>>>>
>>>>>>>> github Build and Test here:
>>>>>>>> https://github.com/gvrose8192/ovs-experimental/actions/runs/463987690
>>>>>>>>
>>>>>>>> 1. 
>>>>>>>> https://mail.openvswitch.org/pipermail/ovs-dev/2020-December/378831.html
>>>>>>>>
>>>>>>>> Greg Rose (2):
>>>>>>>>      doc: Deprecate the Linux Out of Tree drivers
>>>>>>>>      acinclude: Warn when --with-linux parameter is supplied
>>>>>>>>
>>>>>>>>     Documentation/faq/releases.rst | 7 ++++++-
>>>>>>>>     NEWS                           | 3 +++
>>>>>>>>     acinclude.m4                   | 1 +
>>>>>>>>     3 files changed, 10 insertions(+), 1 deletion(-)
>>>>>>>>
>>>>>>>
>>>>>>> Thanks for the patches!
>>>>>>>
>>>>>>> Few general comments:
>>>>>>>
>>>>>>> 1. Word 'driver' sounds weird to me.  'kennel module' is more commonly
>>>>>>>       used term, I think.  We're using term 'driver' for windows 
>>>>>>> datapath,
>>>>>>>       but it seems like windows-specific thing.  In Linux world 
>>>>>>> 'driver' is
>>>>>>>       usually something that talks directly to hardware and that is not
>>>>>>>       the case for openvswitch.ko and other parts.
>>>>>>>       I'd say that we need to do s/kernel driver/kernel module/ in this
>>>>>>>       patch set.
>>>>>>
>>>>>> Sure, not a problem.
>>>>>>
>>>>>>>
>>>>>>> 2. We need to specify the date of removal in NEWS and docs.  I'd say
>>>>>>>       that we could state that OOT kernel module will be removed in 
>>>>>>> 2.16.
>>>>>>>       BTW, from the development point of view it might be good to remove
>>>>>>>       it as soon as 2.15 branched/released.
>>>>>>
>>>>>> Do we actually want to remove it or just leave it deprecated but still 
>>>>>> there?
>>>>>>
>>>>>> And when we say remove it does that mean just disable the '--with-linux'
>>>>>> configure option or would we be removing all the code as well?  I just
>>>>>> want to make sure we define removal the same way.
>>>>>
>>>>> My understanding is to completely remove all the related code and 
>>>>> documentation.
>>>>> This includes 'datapath' directory and configuration stuff from m4 files.
>>>>
>>>> OK, good to be on the same page.
>>>>
>>>>>
>>>>> Users will be able to build kernel module from the 2.15 branch.  This way
>>>>> we will not need to maintain duplicate of the code on newer branches.
>>>>>
>>>>> One problem here is that OVS 2.15 will reach EOL relatively soon, and 
>>>>> projected
>>>>> EOL for kernel 5.4 is Dec 2025.  We might actually postpone complete 
>>>>> removal
>>>>> until 2.18.  This way we will have OVS 2.17 LTS with kernel module 
>>>>> included.
>>>>> And it will be supported until Feb 2025.  And we might actually increase
>>>>> support time on branch-2.17 just for kernel module until kernel 5.4 
>>>>> reaches EOL.
>>>>> After that we can safely remove OOT module in OVS 2.18, because there will
>>>>> be no supported upstream kernel at this point that OOT module supports.
>>>>>
>>>>> Thoughts?
>>>>
>>>> I'm fine with this plan of action.  I will develop and maintain a side
>>>> branch with the final removal of the Linux kernel datapath so that it
>>>> will be ready to go when needed.  That way I can test it early and be
>>>> on the lookout for unwanted side effects.
>>
>> Hi, Greg.  I guess, it's time to pull the trigger. :)
>>
>> Do you have removal patches handy?
>>
>> Best regards, Ilya Maximets.
> 
> Hi Ilya,
> 
> I've been out on PTO for a bit and am just now reading this.  I do
> not have patches ready for this - but I'll get started ASAP.

No problem.  I don't think there is any rush to get it removed.
But it's better to not make such huge changes at the end of the
release cycle.  So, sooner is better.

Thanks!

Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to