Unify KVM kernel-space and user-space code into a single project
in [Kernel]
|
Prev: [PATCH 1/5] x86-32: Split cache flush handler from simd handler
Next: [RESEND][PATCH 1/3] Add tracing_off_event() to stop tracing when a bug or warning occur
From: Frederic Weisbecker on 18 Mar 2010 14:30 On Thu, Mar 18, 2010 at 12:32:51PM +0200, Avi Kivity wrote: > By "serious developer" I mean > > - someone who is interested in contributing, not in getting their name > into the kernel commits list > - someone who is willing to read the wiki page and find out where the > repository and mailing list for a project is > - someone who will spend enough time on the project so that the time to > clone two repositories will not be a factor in their contributions I'm not going to argue about the Qemu merging here. But your above assessment is incomplete. It is not because developers don't want to clone two different trees that tools/perf is a success. Or may be it's a factor but I suspect it to be very minimal. I can script git commands if needed. It is actually because both kernel and user side are sync in this scheme. > Let's wait and see then. If the tools/perf/ experience has really good > results, we can reconsider this at a later date. I think it has already really good results. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: oerg Roedel on 22 Mar 2010 07:20 On Sun, Mar 21, 2010 at 09:31:21PM +0100, Ingo Molnar wrote: > Lets see one example of that thought process in action: Oprofile. Since you are talking so much about oProfile in this thread I think it is important to mention that the problem with oProfile was not the repository separation. The problem was (and is) that the kernel and the user-space parts are maintained by different people who dont talk to each other or have a direction where they want to go with the project. Basically the reason of the oProfile failure is a disfunctional community. I told the kernel-maintainer several times to also maintain user-space but he didn't want that. The situation with KVM is entirely different. Avi commits to kvm.git and qemu-kvm.git so he maintains both. Anthony is working to integrate the qemu-kvm changes into upstream qemu. Further these people work very closely together and the community around KVM works well too. The problems that oProfile has are not even in sight for KVM. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Richard W.M. Jones on 22 Mar 2010 09:30 On Mon, Mar 22, 2010 at 01:05:13PM +0000, Daniel P. Berrange wrote: > This is close to the way libguestfs already works. It boots QEMU/KVM pointing > to a minimal stripped down appliance linux OS image, containing a small agent > it talks to over some form of vmchannel/serial/virtio-serial device. Thus the > kernel in the appliance it runs is the only thing that needs to know about the > filesystem/lvm/dm on-disk formats - libguestfs definitely does not want to be > duplicating this detailed knowledge of on disk format itself. It is doing > full read-write access to the guest filesystem in offline mode - one of the > major use cases is disaster recovery from a unbootable guest OS image. As Dan said, the 'daemon' part is separate and could be run as a standard part of a guest install, talking over vmchannel to the host. The only real issue I can see is adding access control to the daemon (currently it doesn't need it and doesn't do any). Doing it this way you'd be leveraging the ~250,000 lines of existing libguestfs code, bindings in multiple languages, tools etc. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Joerg Roedel on 22 Mar 2010 09:50 On Mon, Mar 22, 2010 at 01:22:28PM +0100, Ingo Molnar wrote: > > * Joerg Roedel <joro(a)8bytes.org> wrote: > > > [...] Basically the reason of the oProfile failure is a disfunctional > > community. [...] > > Caused by: repository separation and the inevitable code and social fork a > decade later. No, the split-repository situation was the smallest problem after all. Its was a community thing. If the community doesn't work a single-repo project will also fail. Look at the state of the alpha arch in Linux today, it is maintained in one repository but nobody really cares about it. Thus it is miles behine most other archs Linux supports today in quality and feature completeness. > What you fail to realise (or what you fail to know, you werent around when > Oprofile was written, i was) is that Oprofile _did_ have a functional single > community when it was written. The tooling and the kernel bits was written by > the same people. Yes, this was probably the time when everybody was enthusiastic about the feature and they could attract lots of developers. But situation changed over time. > So i dont see much of a difference to the Oprofile situation really and i see > many parallels. I also see similar kinds of desktop usability problems. The difference is that KVM has a working community with good developers and maintainers. > The difference is that we dont have KVM with a decade of history and we dont > have a 'told you so' KVM reimplementation to show that proves the point. I > guess it's a matter of time before that happens, because Qemu usability is so > absymal today - so i guess we should suspend any discussions until that > happens, no need to waste time on arguing hypoteticals. We actually have lguest which is small. But it lacks functionality and the developer community KVM has attracted. > I think you are rationalizing the status quo. I see that there are issues with KVM today in some areas. You pointed out the desktop usability already. I personally have trouble with the qem-kvm.git because it is unbisectable. But repository unification doesn't solve the problem here. The point for a single repository is that it simplifies the development process. I agree with you here. But the current process of KVM is not too difficult after all. I don't have to touch qemu sources for most of my work on KVM. > It's as if you argued in 1990 that the unification of East and West Germany > wouldnt make much sense because despite clear problems and incompatibilites > and different styles westerners were still allowed to visit eastern relatives > and they both spoke the same language after all ;-) Um, hmm. I don't think these situations have enough in common to compare them ;-) Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Richard W.M. Jones on 22 Mar 2010 10:20
On Mon, Mar 22, 2010 at 02:56:47PM +0100, Ingo Molnar wrote: > Just curious: any plans to extend this to include live read/write access as > well? > > I.e. to have the 'agent' (guestfsd) running universally, so that > tools such as perf and by users could rely on the VFS integration as > well, not just disaster recovery tools? Totally. That's not to say there is a definite plan, but we're very open to doing this. We already wrote the daemon in such a way that it doesn't require the appliance part, but could run inside any existing guest (we've even ported bits of it to Windoze ...). The only remaining issue is how access control would be handled. You obviously wouldn't want anything in the host that can get access to the vmchannel socket to start sending destructive write commands into guests. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |