From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [ANNOUNCE] Native Linux KVM tool Date: Fri, 08 Apr 2011 09:39:47 +0200 Message-ID: <4D9EBBC3.2040803@siemens.com> References: <1301592656.586.15.camel@jaguar> <4D982E89.8070502@redhat.com> <4D9847BC.9060906@redhat.com> <4D98716D.9040307@codemonkey.ws> <4D9873CD.3080207@redhat.com> <20110406093333.GB6465@elte.hu> <4D9E6F6E.9050709@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , Ingo Molnar , Avi Kivity , linux-kernel@vger.kernel.org, aarcange@redhat.com, mtosatti@redhat.com, kvm@vger.kernel.org, joro@8bytes.org, penberg@cs.helsinki.fi, asias.hejun@gmail.com, gorcunov@gmail.com To: Pekka Enberg Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 2011-04-08 07:14, Pekka Enberg wrote: > Hi Anthony, > > On Fri, Apr 8, 2011 at 5:14 AM, Anthony Liguori wrote: >> If someone was going to seriously go about doing something like this, a >> better approach would be to start with QEMU and remove anything non-x86 and >> all of the UI/command line/management bits and start there. >> >> There's nothing more I'd like to see than a viable alternative to QEMU but >> ignoring any of the architectural mistakes in QEMU and repeating them in a >> new project isn't going to get there. > > Hey, feel free to help out! ;-) > > I don't agree that a working 2500 LOC program is 'repeating the same > architectural mistakes' as QEMU. I hope you realize that we've gotten > here with just three part-time hackers working from their proverbial > basements. So what you call mistakes, we call features for the sake of > simplicity. > > I also don't agree with this sentiment that unless we have SMP, > migration, yadda yadda yadda, now, it's impossible to change that in > the future. It ignores the fact that this is exactly how the Linux > kernel evolved and the fact that we're aggressively trying to keep the > code size as small and tidy as possible so that changing things is as > easy as possible. 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. Jan (*) I would consider Anthony's idea to drop anything !=x86 a mistake given where KVM is moving to, today on PPC, tomorrow likely on ARM - just to name two examples. -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux