On Tue, Aug 18, 2009 at 11:39:25AM -0400, Gregory Haskins wrote: > Michael S. Tsirkin wrote: > > On Mon, Aug 17, 2009 at 03:33:30PM -0400, Gregory Haskins wrote: > >> There is a secondary question of venet (a vbus native device) verses > >> virtio-net (a virtio native device that works with PCI or VBUS). If > >> this contention is really around venet vs virtio-net, I may possibly > >> conceed and retract its submission to mainline. > > > > For me yes, venet+ioq competing with virtio+virtqueue. > > > >> I've been pushing it to date because people are using it and I don't > >> see any reason that the driver couldn't be upstream. > > > > If virtio is just as fast, they can just use it without knowing it. > > Clearly, that's better since we support virtio anyway ... > > More specifically: kvm can support whatever it wants. I am not asking > kvm to support venet. > > If we (the alacrityvm community) decide to keep maintaining venet, _we_ > will support it, and I have no problem with that. > > As of right now, we are doing some interesting things with it in the lab > and its certainly more flexible for us as a platform since we maintain > the ABI and feature set. So for now, I do not think its a big deal if > they both co-exist, and it has no bearing on KVM upstream. As someone who extended them recently, both ABI and feature set with virtio are pretty flexible. What's the problem? Will every single contributor now push a driver with an incompatible ABI upstream because this way he maintains both ABI and feature set? Oh well ... -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
