Hi Alessandro, >>> >>> In short, both implementations have strengths and weaknesses. Each of >>> them could evolve by eliminating their weaknesses and adding the >>> strengths of the other, converging to meet somewhere in the middle, >>> but this would duplicate work and waste developer time. A better >>> approach would be for both teams to collaborate on a common codebase. >>> >>> Here is what I want to do: >>> >>> * Apply the next version of Alin's series to support Netlink >>> userspace for Windows (as long as it doesn't break other >>> platforms) to master. >>> >>> * Apply the next version of the VMware patch series to add Windows >>> kernel support, again assuming that it doesn't break other >>> platforms. It is my judgment that, on balance, this is a better >>> place to start. >>> >>> At this point we will have Windows userspace and kernel support, >>> but they will be incompatible because they do not understand the >>> same protocol. >> >> This sounds great, Ben. I would like to suggest a slight modification. >>May >> be this is something that you already considered and rejected. But, do >>you >> think we could commit the Netlink support from Cloudbase and both the >> userspace & kernel space support from VMWare? (I think both the >> Userspace's should be able to coexist.) This will allow the windows port >> to be functional and hence incremental features (such as GRE, etc) can >>be >> tested during development & they don¹t have to wait for the user/kernel >> integration to be complete. Obviously, once the Netlink support is fully >> integrated, we would have to rip out the VMWare userspace support (which >> is extra effort). > >I don’t see the point in adding non-Netlink userspace features at this >stage as >anyway they need to be removed. >IMHO the best option that we have is to concentrate in producing the >kernel >side Netlink implementation by working with both Cloudbase and VMWare >codebases. > >This would also need to be among the first patchsets submitted for review. > >Thanks, > >Alessandro
Alright, this is fine too. I would have liked to keep the port functional so that folks, who are not involved in the Netlink integration effort, can still test & submit patches. The VMware userspace change primarily lives in two files - dpif-windows & netdev-windows (and some fringe changes), which would have been pretty easy to rip out. Anyways, lets work towards getting the kernel Netlink implementation in, asap! Thanks, Saurabh _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
