Yifeng Sun <pkusunyif...@gmail.com> writes: > Thanks for your review. > > Since CONFIG_MODVERSIONS is default to 'y' in most cases, I'd say this > is to circumvent CONFIG_MODVERSIONS=y. > > This happened when redhat kernel was upgraded from > 3.10.0-514.el7.x86_64 to 3.10.0-693.1.1.el7.x86_64. When 693 uses the > openvswitch.ko built for 514, some error happened.
Maybe you want something like a dkms module? I'm not sure. I do know that RHEL ships an openvswitch.ko which is kept up to date with upstream, and should have been shipped with the kernel. Is that not the case? > On Wed, Dec 13, 2017 at 10:24 AM, Aaron Conole <acon...@redhat.com> wrote: > > Yifeng Sun <pkusunyif...@gmail.com> writes: > > > Deployment and upgrade failure is quite often caused by that > openvswitch.ko was > > built upon kernel x.y.z-release-A while it is loaded into a running kernel > > of x.y.z-release-B. This patch proposes to enforce the matching of the two > > kernel release numbers at the moment of deployment and upgrading. > > > > Signed-off-by: Yifeng Sun <pkusunyif...@gmail.com> > > --- > > Is this to circumvent CONFIG_MODVERSIONS=n? > > This seems like a situation that shouldn't happen. When upgrading, the > installed version (make modules_install) should be matched (ie: a > modprobe won't work because the kernel `uname -r` directory changed). > Otherwise, a new build should be done by the developer that changed out > their kernel (because they are manually building OvS modules and > installing from the source tree). > > I'm probably not understanding the use case. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
