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