Ingo Molnar wrote: > * Gregory Haskins <gregory.haskins@xxxxxxxxx> 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. (You mean vbus vs pci, right? virtio works fine, is untouched, and is 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 above > now basically boils down to: "because I want it so, why dont you > leave me alone". Well, with all due respect, please do not put words in my mouth. This 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. > > What you are doing here is to in essence to fork KVM, No, that is incorrect. What I am doing here is a downstream development point for the integration of KVM and vbus. Its akin to kvm.git or tip.git to develop a subsystem intended for eventual inclusion upstream. If and when the code goes upstream in a manner acceptable to all parties involved, and AlacrityVM exceeds its utility as a separate project, I will _gladly_ dissolve it and migrate to use upstream KVM instead. As stated on the project wiki: "It is a goal of AlacrityVM to work towards upstream acceptance of the project on a timeline that suits the community. In the meantime, this wiki will serve as the central coordination point for development and discussion of the technology" (citation: http://developer.novell.com/wiki/index.php/AlacrityVM) And I meant it when I said it. Until then, the project is a much more efficient way for us (the vbus developers) to work together than pointing people at my patch series posted to kvm@vger. I tried that way first. It sucked, and didn't work. Users were having trouble patching the various pieces, building, etc. Now I can offer a complete solution from a central point, with all the proper pieces in place to play around with it. Ultimately, it is up to upstream to decide if this is to become merged or remain out of tree forever as a "fork". Not me. I will continue to make every effort to find common ground with my goals coincident with the blessing of upstream, as I have been from the beginning. Now I have a more official forum to do it in. > 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) In an ideal world, perhaps. Avi and I currently have a fundamental disagreement about the best way to do PV. He sees the world through PCI glasses, and I don't. Despite attempts on both sides to rectify this disagreement, we currently do not see eye to eye on every front. This doesn't mean he is right, and I am wrong per se. It just means we disagree. Period. Avi is a sharp guy, and I respect him. But upstream KVM doesn't have a corner on "correct" ;) The community as a whole will ultimately decide if my ideas live or die, wouldn't you agree? Avi can correct me if I am wrong, but what we _do_ agree on is that core KVM doesn't need to be directly involved in this vbus (or vhost) discussion, per se. It just wants to have the hooks to support various PV solutions (such as irqfd/ioeventfd), and vbus is one such solution. > > 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. Im sorry, but you are mistaken: http://lkml.indiana.edu/hypermail/linux/kernel/0904.2/02443.html > 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. I really do not think you are in a position to say when someone can or cannot fork a project, so please do not try to lecture on that. Perhaps you could offer advice on when someone, in your opinion, *should* or *should not* fork, because that would be interesting to hear. 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, > administrators, packagers it's a big deal whether two overlapping > pieces of functionality for the same thing exist within the same > kernel. So the only thing that could be construed as overlapping here is venet 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? > 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()? No, and I am not advocating that either. > > I certainly dont want that. Instead we (at great expense and work) > try to reach the best technical solution. This is all I want, as well. > 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 call it like I see it. I get private emails all the time encouraging my efforts and asking about the project. I'm sorry if you see this as hand-waving. Perhaps the people involved will become more vocal in the community to back me up, perhaps not. Time will tell. > I can assure you, users _DONT WANT_ split > interfaces and incompatible drivers for the same thing. They want > stuff that works well. And I can respect that, and am trying to provide that. > > If the community wants this then why cannot you convince one of the > most prominent representatives of that community, the KVM > developers? Its a chicken and egg at times. Perhaps the KVM developers do not have the motivation or time to properly consider such a proposal _until_ the community presents its demand. And sometimes you cannot build demand unless you have an easy way to use the idea, such as a project to back it. Since vbus+kvm has many moving parts (guest side, host-side, userspace-side, etc), its difficult to use as a patch series pulled in from a mailing list. This is the role of the AlacrityVM project. Make it easy to use and develop. If it draws a community, perhaps KVM will reconsider its stance. If it does not draw a community, it will naturally die. End of story. But please do not confuse one particular groups opinion as the sole validation of an idea, no matter how "prominent". There are numerous reasons why one group may hold an opinion that have nothing to do with the actual technical merits of the idea, or the community demand for it. > > Furthermore, 99% of your work is KVM Actually, 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. ;) > why dont you respect that work by not forking it? Lighten up on the fork FUD, please. It's counter productive. Kind Regards, -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
