This thread started because i asked you about your technical(You mean vbus vs pci, right? virtio works fine, is untouched, and is
arguments why we'd want vbus instead of virtio.
out-of-scope here)
Right, and I do believe I answered your questions. Do you feel as
though this was not a satisfactory response?
Your answer aboveWell, with all due respect, please do not put words in my mouth. This
now basically boils down to: "because I want it so, why dont you
leave me alone".
is not what I am saying at all.
What I *am* saying is:
fact: this thread is about linux guest drivers to support vbus
fact: these drivers do not touch kvm code.
fact: these drivers to not force kvm to alter its operation in any way.
fact: these drivers do not alter ABIs that KVM currently supports.
Therefore, all this talk about "abandoning", "supporting", and
"changing" things in KVM is, premature, irrelevant, and/or, FUD. No one
proposed such changes, so I am highlighting this fact to bring the
thread back on topic. That KVM talk is merely a distraction at this
point in time.
We all love faster code and better management interfaces and tonsIm sorry, but you are mistaken:
of your prior patches got accepted by Avi. This time you didnt even
_try_ to improve virtio.
http://lkml.indiana.edu/hypermail/linux/kernel/0904.2/02443.html
You are also wrong to say that I didn't try to avoid creating a
downstream effort first. I believe the public record of the mailing
lists will back me up that I tried politely pushing this directly though
kvm first. It was only after Avi recently informed me that they would
be building their own version of an in-kernel backend in lieu of working
with me to adapt vbus to their needs that I decided to put my own
project together.
What should I have done otherwise, in your opinion?
And fragmentation matters quite a bit. To Linux users, developers,So the only thing that could be construed as overlapping here is venet
administrators, packagers it's a big deal whether two overlapping
pieces of functionality for the same thing exist within the same
kernel.
vs virtio-net. If I dropped the contentious venet and focused on making
a virtio-net backend that we can all re-use, do you see that as a path
of compromise here?
I certainly dont want that. Instead we (at great expense and work)This is all I want, as well.
try to reach the best technical solution.
If the community wants this then why cannot you convince one of theIts a chicken and egg at times. Perhaps the KVM developers do not have
most prominent representatives of that community, the KVM
developers?
the motivation or time to properly consider such a proposal _until_ the
community presents its demand.
Furthermore, 99% of your work is KVMActually, no. Almost none of it is. I think there are about 2-3
patches in the series that touch KVM, the rest are all original (and
primarily stand-alone code). AlacrityVM is the application of kvm and
vbus (and, of course, Linux) together as a complete unit, but I do not
try to hide this relationship.
By your argument, KVM is 99% QEMU+Linux. ;)