On 2011-04-08 10:27, Pekka Enberg wrote: > Hi Jan, > > On Fri, 2011-04-08 at 09:39 +0200, Jan Kiszka wrote: >> I agree that it's easy to change 2kSomething LOC for this. But if you >> now wait too long designing in essential features like SMP, a scalable >> execution model, and - very important - portability (*), it can get >> fairly painful to fix such architectural deficits later on. How long did >> it take for Linux to overcome the BKL? QEMU is in the same unfortunate >> position. > > Yup, and we're taking your feedback seriously (and are thankful for > it!). We're hoping to look at SMP in the near future - help is > appreciated! Honestly, I do not yet see a major advantage for us to invest here instead of / in addition to continuing to improve QEMU. We've spend quite some effort on the latter with IMO noteworthy results. Porting over qemu-kvm to upstream was and still is among those efforts. We (*) are "almost done". :) Just one example: Despite QEMU's current deficits, I just have add a handful of (ad-hoc) patches to turn it into a (soft) real-time hypervisor, and that also for certain non-Linux guests. Your approach is yet man years of development and stabilization effort away from getting close to such a level. Don't want to discourage you or other contributors. I wish you that this approach can gather the critical mass and momentum to make it a real alternative, at least for a subset of use cases. We will surely keep an eye on it and re-assess its pros&cons as it progresses. Jan (*) the QEMU & KVM community -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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
