[lkml]   [2009]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v3 3/6] vbus: add a "vbus-proxy" bus model for vbus_driver objects
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:
> 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:
> 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
> (;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

 \ /
  Last update: 2009-08-17 17:17    [W:0.164 / U:3.356 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site