Re: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects

[Avi Kivity <avi@redhat.com>]

On 08/17/2009 06:05 PM, Gregory Haskins wrote:
> Hi Ingo,
>
> 1) First off, let me state that I have made every effort to propose this
> as a solution to integrate with KVM, the most recent of which is April:
>
> http://lkml.org/lkml/2009/4/21/408
>
> If you read through the various vbus related threads on LKML/KVM posted
> this year, I think you will see that I made numerous polite offerings to
> work with people on finding a common solution here, including Michael.
>
> In the end, Michael decided that go a different route using some of the
> ideas proposed in vbus + venet-tap to create vhost-net.  This is fine,
> and I respect his decision.  But do not try to pin "fracturing" on me,
> because I tried everything to avoid it. :)
>    

Given your post, there are only three possible ways to continue kvm 
guest driver development:

- develop virtio/vhost, drop vbus/venet
- develop vbus/venet, drop virtio
- develop both

Developing both fractures the community.   Dropping virtio invalidates 
the installed base and Windows effort.  There were no strong technical 
reasons shown in favor of the remaining option.


> Since I still disagree with the fundamental approach of how KVM IO
> works,

What's that?

> Prior to my effort, KVM was humming along at the status quo and I came
> along with a closer eye and almost doubled the throughput and cut
> latency by 78%.  Given an apparent disagreement with aspects of my
> approach, Michael went off and created a counter example that was
> motivated by my performance findings.
>    

Oh, virtio-net performance was a thorn in our side for a long time.  I 
agree that venet was an additional spur.

> Therefore, even if Avi ultimately accepts Michaels vhost approach
> instead of mine, Linux as a hypervisor platform has been significantly
> _improved_ by a little friendly competition, not somehow damaged by it.
>    

Certainly, and irqfd/ioeventfd are a net win in any case.

> 4) Lastly, these patches are almost entirely just stand alone Linux
> drivers that do not affect KVM if KVM doesn't wish to acknowledge them.
>   Its just like any of the other numerous drivers that are accepted
> upstream into Linux every day.  The only maintained subsystem that is
> technically touched by this series is netdev, and David Miller already
> approved of the relevant patch's inclusion:
>
> http://lkml.org/lkml/2009/8/3/505
>
> So with all due respect, where is the problem?  The patches are all
> professionally developed according to the Linux coding standards, pass
> checkpatch, are GPL'ed, and work with a freely available platform which
> you can download today
> (http://git.kernel.org/?p=linux/kernel/git/ghaskins/alacrityvm/linux-2.6.git;a=summary)
>    

As I mentioned before, I have no technical objections to the patches, I 
just wish the effort could be concentrated in one direction.

-- 
error compiling committee.c: too many arguments to function