* Gregory Haskins <gregory.hask...@gmail.com> wrote:
> > You haven't convinced me that your ideas are worth the effort
> > of abandoning virtio/pci or maintaining both venet/vbus and
> > virtio/pci.
>
> With all due respect, I didnt ask you do to anything, especially
> not abandon something you are happy with.
>
> All I did was push guest drivers to LKML. The code in question
> is independent of KVM, and its proven to improve the experience
> of using Linux as a platform. There are people interested in
> using them (by virtue of the number of people that have signed up
> for the AlacrityVM list, and have mailed me privately about this
> work).
This thread started because i asked you about your technical
arguments why we'd want vbus instead of virtio. Your answer above
now basically boils down to: "because I want it so, why dont you
leave me alone".
What you are doing here is to in essence to fork KVM, regardless of
the technical counter arguments given against such a fork and
regardless of the ample opportunity given to you to demostrate the
technical advantages of your code. (in which case KVM would happily
migrate to your code)
We all love faster code and better management interfaces and tons
of your prior patches got accepted by Avi. This time you didnt even
_try_ to improve virtio. It's not like you posted a lot of virtio
patches which were not applied. You didnt even try and you need to
try _much_ harder than that before forking a project.
And fragmentation matters quite a bit. To Linux users, developers,
administrators, packagers it's a big deal whether two overlapping
pieces of functionality for the same thing exist within the same
kernel. The kernel is not an anarchy where everyone can have their
own sys_fork() version or their own sys_write() version. Would you
want to have two dozen read() variants, sys_read_oracle() and a
sys_read_db2()?
I certainly dont want that. Instead we (at great expense and work)
try to reach the best technical solution. That means we throw away
inferior code and adopt the better one. (with a reasonable
migration period)
You are ignoring that principle with hand-waving about 'the
community wants this'. I can assure you, users _DONT WANT_ split
interfaces and incompatible drivers for the same thing. They want
stuff that works well.
If the community wants this then why cannot you convince one of the
most prominent representatives of that community, the KVM
developers?
Furthermore, 99% of your work is KVM, why dont you respect that
work by not forking it? Why dont you respect the KVM community and
Linux in general by improving existing pieces of infrastructure
instead of forcefully forking it?
Ingo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
