Unify KVM kernel-space and user-space code into a single project
in [Kernel]
|
Prev: Irish 2010 Grant Winner
Next: [PATCH] staging: winbond: mds_f.h whitespace and CamelCase corrections.
From: Avi Kivity on 22 Mar 2010 08:50 On 03/22/2010 01:23 PM, Ingo Molnar wrote: > * Avi Kivity<avi(a)redhat.com> wrote: > > >> IMO the reason perf is more usable than oprofile has less to do with the >> kernel/userspace boundary and more do to with effort and attention spent on >> the userspace/user boundary. >> >> [...] >> > If you are interested in the first-hand experience of the people who are doing > the perf work then here it is: by far the biggest reason for perf success and > perf usability is the integration of the user-space tooling with the > kernel-space bits, into a single repository and project. > Please take a look at the kvm integration code in qemu as a fraction of the whole code base. > The very move you are opposing so vehemently for KVM. > I don't want to fracture a working community. > Oprofile went the way you proposed, and it was a failure. It failed not > because it was bad technology (it was pretty decent and people used it), it > was not a failure because the wrong people worked on it (to the contrary, very > capable people worked on it), it was a failure in hindsight because it simply > incorrectly split into two projects which stiffled the progress of each other. > Every project that has some kernel footprint, except perf, is split like that. Are they all failures? Seems like perf is also split, with sysprof being developed outside the kernel. Will you bring sysprof into the kernel? Will every feature be duplicated in prof and sysprof? -- error compiling committee.c: too many arguments to function -- 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: Ingo Molnar on 22 Mar 2010 08:50 * Avi Kivity <avi(a)redhat.com> wrote: > On 03/22/2010 01:14 PM, Ingo Molnar wrote: > > > >>I think we agree at last. Neither I nor my employer are interested in > >>running qemu as a desktop-on-desktop tool, therefore I don't invest any > >>effort in that direction, or require it from volunteers. > >Obviously your employer at least in part defers to you when it comes to KVM > >priorities. > > In part, yes. > > > So, just to make this really clear, _you_ are not interested in running > > qemu as a desktop-on-desktop tool, subsequently this kind of > > disinterest-for-desktop-usability trickled through the whole KVM stack and > > poisoned your attitude and your contributor's attitude. > > I am also disinterested in ppc virtualization, yet it happened. I am > disinterested in ia64 virtualization, yet it happened. I am disinterested > in s390 virtualization, yet it happened. > > Linus doesn't care about virtualization, yet it happened. You should know the answer yourself: the difference is that usability is a core quality of any project. I as a maintainer can be neutral towards a number of features and patch attributes that i dont consider key aspects. (although they can grow out to become key features in the future. SMP was a fringe thing 15 years ago.) Usability is not an attribute you can ignore and i for sure am never neutral towards usability deficiencies in patches - i consider usability a key quality. > I don't tell my contributor what to be interested in, only whether their > patches are good or not. [...] Whether a feature is usable or not is sure a metric of 'goodness'. You have restricted your metric of goodness artificially to not include usability. You do that by claiming that the user-space tooling of KVM, while being functionally absolutely essential for any user to even try out KVM, is 'separate' and has no quality connection with the kernel bits of KVM. It is a convenient argument that allows you to do the kernel bits only. It is absolutely catastrophic to the user who'd like to see a usable solution and a single project who stands behind their tech. Thus, _today_, after years of neglect, you can claim that none of the dozens of usability problems of KVM has anything to do with the features you are working on today. It's in a separate project (the so-called 'Qemu' package) after all - none of KVM's business. In reality if you consider it a single project then those bugs were all usability problems introduced earlier on, years ago, when a piece of functionality was exposed via KVM. It adds up and now you claim they have nothing to do with current work. This is why i consider that line of argument rather dishonest ... Ingo -- 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: Pekka Enberg on 22 Mar 2010 08:50 Hi Daniel, (I'm getting slightly off-topic, sorry about that.) Daniel P. Berrange kirjoitti: >>> Here it is, repeated for the Nth time: >>> >>> Allow a guest to (optionally) integrate its VFS namespace with the host side >>> as well. An example scheme would be: >>> >>> /guests/Fedora-G1/ >>> /guests/Fedora-G1/proc/ >>> /guests/Fedora-G1/usr/ >>> /guests/Fedora-G1/.../ >>> /guests/OpenSuse-G2/ >>> /guests/OpenSuse-G2/proc/ >>> /guests/OpenSuse-G2/usr/ >>> /guests/OpenSuse-G2/.../ >>> >>> ( This feature would be configurable and would be default-off, to maintain >>> the current status quo. ) >> Heh, funny. That would also solve my number one gripe with >> virtualization these days: how to get files in and out of guests >> without having to install extra packages on the guest side and >> fiddling with mount points on every single guest image I want to play >> with. > > FYI, for offline guests, you can use libguestfs[1] to access & change files > inside the guest, and read-only access to running guests files. It provides > access via a interactive shell, APIs in all major languages, and also has a > FUSE mdule to expose it directly in the host VFS. It could probably be made > to work read-write for running guests too if its agent were installed inside > the guest & leverage the new Virtio-Serial channel for comms (avoiding any > network setup requirements). Right. Thanks for the pointer. The use case I am thinking of is working on an userspace project and wanting to test a piece of code on multiple distributions before pushing it out. That pretty much means being able to pull from the host git repository (or push to the guest repo) while the guest is running, maybe changing the code a bit and then getting the changes back to the host for the final push. What I do now is I push the changes on the host side to a (private) remote branch and do the work through that. But that's pretty lame workaround in my opinion. Pekka -- 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: Avi Kivity on 22 Mar 2010 09:00 On 03/22/2010 02:44 PM, Ingo Molnar wrote: > This is why i consider that line of argument rather dishonest ... > I am not going to reply to any more email from you on this thread. -- error compiling committee.c: too many arguments to function -- 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: Ingo Molnar on 22 Mar 2010 09:00
* Daniel P. Berrange <berrange(a)redhat.com> wrote: > On Mon, Mar 22, 2010 at 02:31:49PM +0200, Pekka Enberg wrote: > > On Mon, Mar 22, 2010 at 1:48 PM, Ingo Molnar <mingo(a)elte.hu> wrote: > > >> What about line number information? ?And the source? ?Into the kernel with > > >> them as well? > > > > > > Sigh. Please read the _very first_ suggestion i made, which solves all that. I > > > rarely go into discussions without suggesting technical solutions - i'm not > > > interested in flaming, i'm interested in real solutions. > > > > > > Here it is, repeated for the Nth time: > > > > > > Allow a guest to (optionally) integrate its VFS namespace with the host side > > > as well. An example scheme would be: > > > > > > ? /guests/Fedora-G1/ > > > ? /guests/Fedora-G1/proc/ > > > ? /guests/Fedora-G1/usr/ > > > ? /guests/Fedora-G1/.../ > > > ? /guests/OpenSuse-G2/ > > > ? /guests/OpenSuse-G2/proc/ > > > ? /guests/OpenSuse-G2/usr/ > > > ? /guests/OpenSuse-G2/.../ > > > > > > ?( This feature would be configurable and would be default-off, to maintain > > > ? ?the current status quo. ) > > > > Heh, funny. That would also solve my number one gripe with virtualization > > these days: how to get files in and out of guests without having to > > install extra packages on the guest side and fiddling with mount points on > > every single guest image I want to play with. > > FYI, for offline guests, you can use libguestfs[1] to access & change files > inside the guest, and read-only access to running guests files. It provides > access via a interactive shell, APIs in all major languages, and also has a > FUSE mdule to expose it directly in the host VFS. It could probably be made > to work read-write for running guests too if its agent were installed inside > the guest & leverage the new Virtio-Serial channel for comms (avoiding any > network setup requirements). > > Regards, > Daniel > > [1] http://libguestfs.org/ Yes, this is the kind of functionality i'm suggesting. I'd suggest a different implementation for live guests: to drive this from within the live guest side of KVM, i.e. basically a paravirt driver for guestfs. You'd pass file API guests to the guest directly, via the KVM ioctl or so - and get responses from the guest. That will give true read-write access and completely coherent (and still transparent) VFS integration, with no host-side knowledge needed for the guest's low level (raw) filesystem structure. That's a big advantage. Yes, it needs an 'aware' guest kernel - but that is a one-off transition overhead whose cost is zero in the long run. (i.e. all KVM kernels beyond a given version would have this ability - otherwise it's guest side distribution transparent) Even 'offline' read-only access could be implemented by booting a minimal kernel via qemu -kernel and using a 'ro' boot option. That way you could eliminate all lowlevel filesystem knowledge from libguestfs. You could run ext4 or btrfs guest filesystems and FAT ones as well - with no restriction. This would allow 'offline' access to Windows images as well: a FAT or ntfs enabled mini-kernel could be booted in read-only mode. Thanks, Ingo -- 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/ |