On Fri, Dec 2, 2011 at 9:55 AM, Ben Pfaff <b...@nicira.com> wrote: > On Thu, Dec 01, 2011 at 07:55:21PM -0800, Ansis Atteka wrote: > > Some while ago Netlink Family names were changed from ODP_* > > to OVS_*. This leaded to upgrade related issues when the new ovs-dpctl > > wanted to remove existing datapaths from the old kernel module > > by using 'ovs_datapath' instead of 'odp_datapath' name. > > > > Issue #8548 > > I believe that adding some compatibility is the right approach, but I > think that this is not the right way to do it. > > We can't modify include/linux/openvswitch.h for this because that file > is supposed to go upstream. > > I don't think that we should make dpif-linux.c treat the older > "odp_datapath" identically to the newer "ovs_datapath", because there > are undoubtedly important changes that will cause many (most?) > operations to fail in the older protocol. > I mostly agree with this.
I haven't looked into GIT history how much our Netlink protocol has changed between odp_datapath and ovs_datapath, so I do not have strong opinion about this. But the thing is that operations can also fail between two different ovs_datapath versions that go under the same name as well. In the past ovs-dpctl has always tried to treat two different versions of ovs_datapath the same way. And the commit that changed odp_* to ovs_* was pure refactoring. That was the reason why I thought that using them as fall-back alias would not be more risky than what we have been doing all the time. > I would: > > * Put the definitions we need in a separate header file. > Ok. > > * Log a warning when the fallback datapath is opened. > Ok. > > * Support only the most basic operations, e.g. dump, open, > close, destroy, and fail the rest with an error. Agree. Initially I wanted to go the same approach by limiting fall-back only to ovs-dpctl commands that are needed to unload the kernel module. But If I understand it correctly then this would require in dpif_linux_init() knowledge whether it is being called from ovs-dpctl and what operations user wants to execute. Will look into this. > I think it might be reasonable, in fact, to define this as a > completely separate dpif named, e.g., "linux-old" in a file like > lib/dpif-linux-old.c. That would make it very easy to remove later. >
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
