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. 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
