* Alexander Graf <agraf@xxxxxxx> wrote: > > In fact one of the problems i see with Qemu is that Qemu had to > > make many compromises to support Windows and other weird > > platforms that i'm (and i'd claim most other Linux kernel > > developers) are personally not interested in. > > It's what makes it so powerful. [...] To me and Pekka that is what made Qemu unhackable. Really, i'm not sure why you are arguing here. We are not trying to merge tools/qemu/ upstream. We are trying to merge a Linux-only utility that lives in the kernel tree today and which we are actively using and developing. > [...] Adding a new architecture for KVM for example is as easy as > only implementing the CPU. All device emulation is already there. > If you want something Linux only, lguest would've been enough, no? That's a rather bizarre argument, we were pretty happy with the design of the KVM host side, what we wanted to improve was user-space tooling. With lguest we'd have to write a new host implementation in essence ... > > [...] > > > > tools/kvm/ does less and in my experience does it better - is > > that such a surprising thing? > > [...] > > > So it was a no brainer for me to pull it into -tip. > > The thing I don't agree with is that it should live in the kernel > tree. FYI, tools/kvm/ *already* lives in the kernel tree - that is how it's developed and used and it also shares code with the kernel. Thanks, Ingo -- 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
