On 08/18/2009 06:51 PM, Gregory Haskins wrote:
It's not laughably trivial when you try to support the full feature set
of kvm (for example, live migration will require dirty memory tracking,
and exporting all state stored in the kernel to userspace).
Doesn't vhost suffer from the same issue? If not, could I also apply
the same technique to support live-migration in vbus?
It does. There are two possible solutions to that: dropping the entire
protocol to userspace, or the one I prefer, proxying the ring and
eventfds in userspace but otherwise letting vhost-net run normally.
This way userspace gets to see descriptors and mark the pages as dirty.
Both these approaches rely on vhost-net being an accelerator to a
userspace based component, but maybe you can adapt venet to use
something similar.
Oh come on, I wrote "steal" as a convenient shorthand for
"cross-pollinate your ideas into our code according to the letter and
spirit of the GNU General Public License".
Is that supposed to make me feel better about working with you? I mean,
writing, testing, polishing patches for LKML-type submission is time
consuming. If all you are going to do is take those ideas and rewrite
it yourself, why should I go through that effort?
If you're posting your ideas for everyone to read in the form of code,
why not post them in the form of design ideas as well? In any case
you've given up any secrets. In the worst case you've lost nothing, in
the best case you may get some hopefully constructive criticism and
maybe improvements.
I'm perfectly happy picking up ideas from competing projects (and I
have) and seeing my ideas picked up in competing projects (which I also
have).
Really, isn't that the point of open source? Share code, but also share
ideas?
And its not like that was the first time you have said that to me.
And I meant it every time.
Haven't you just asked how vhost-net plans to do live migration?
Since we're all trying to improve Linux we may as well cooperate.
Well, I don't think anyone can say that I haven't been trying.
I'd be obliged if you reveal some of your secret sauce then (only the
parts you plan to GPL anyway of course).
"sorry, we are going to reinvent our own instead".
No. Adopting venet/vbus would mean reinventing something that already
existed.
But yet, it doesn't.
We'll need to do the agree to disagree thing again here.
Continuing to support virtio/pci is not reinventing anything.
No one asked you to do otherwise.
Right, and I'm not keen on supporting both. See why I want to stick to
virtio/pci as long as I possibly can?
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).
So where is the problem here?
I'm unhappy with the duplication of effort and potential fragmentation
of the developer and user communities, that's all. I'd rather see the
work going into vbus/venet going into virtio. I think it's a legitimate
concern.
--
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
