Hi Ilya,
Sorry for top posting but I wanted to leave a note on my progress.
I have some patches to disable the Linux builds and remove the kernel
module specific specification files for RHEL/CENTOS and the associated
documentation updates. There are also a number of automake.mk files
that I had to update. I hope to post them before the EoTW but will
probably do so at first as just an RFC. The kernel datapath headers
are still required for userspace to compile correctly and pulling the
threads apart to separate the userspace and kernel datapath
often results in unexpected complications.
The short story is that I think we'll need a number of iterations
to get through this and I will start with an RFC for the first set
of patches. This will get the conversation started and will help
me identify a lot of things I've probably missed in this first
patch series.
I'll post the RFC patches and get the conversation started by
Friday this week (ends 4/15/22) and we'll see how it goes.
Thanks,
- Greg
On 3/30/2022 1:36 PM, 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.
Thanks,
- Greg
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
