On 08/19/2009 02:40 PM, Gregory Haskins wrote:
So if I whip up a virtio-net backend for vbus with a PCI compliant
connector, you are happy?
This doesn't improve virtio-net in any way.
Any why not? (Did you notice I said "PCI compliant", i.e. over virtio-pci)
Because virtio-net will have gained nothing that it didn't have before.
??
*) ABI is virtio-pci compatible, as you like
That's not a gain, that's staying in the same place.
*) fast-path is in-kernel, as we all like
That's not a gain as we have vhost-net (sure, in development, but your
proposed backend isn't even there yet).
*) model is in vbus so it would work in all environments that vbus supports.
The ABI can be virtio-pci compatible or it can be vbus-comaptible. How
can it be both? The ABIs are different.
Note that if you had submitted a virtio-net backend I'd have asked you
to strip away all the management / bus layers and we'd have ended up
with vhost-net.
virtio already supports this model; see lguest and s390. Transporting
virtio over vbus and vbus over something else doesn't gain anything over
directly transporting virtio over that something else.
This is not what I am advocating.
What are you advocating? As far as I can tell your virtio-vbus
connector plus the vbus-kvm connector is just that.
I wouldn't classify it anything like that, no. Its just virtio over vbus.
We're in a loop. Doesn't virtio over vbus need a virtio-vbus
connector? and doesn't vbus need a connector to talk to the hypervisor?
--
error compiling committee.c: too many arguments to function
--
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
