* Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote: > It's important to understand why one mechanism is better than another. All > I'm looking for is a set of bullet points that say, vbus does this, > vhost-net does that, therefore vbus is better. We would then either say, > oh, that's a good idea, let's change vhost-net to do that, or we would say, > hrm, well, we can't change vhost-net to do that because of some fundamental > flaw, let's drop it and adopt vbus. > > It's really that simple :-) That makes a lot of sense to me. I think we better have damn good technical reasons before we encourage a fork of a subsystem within the kernel. Technical truth is not something we can 'agree to disagree' on, and it is not something we can compromise on really. Both the host and the guest code is in Linux so adding another variant without that variant replacing the old one (on the spot or gradually) makes no technical sense. Gregory, i'd suggest for you to shape this as a "this and this aspect of KVM needs to be replaced/fixed" list of items, as suggested by Anthony. In my experience the KVM folks are very approachable and very reasonable about addressing technical shortcomings and acting upon feedback (and are happily accepting code as well) - so to the extent there's room for improvement here it should be done by shaping KVM, not by forking and rebranding it. Ingo -- 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
