Hi! > Hi Anthony, > > On Fri, Apr 8, 2011 at 5:14 AM, Anthony Liguori <anthony@xxxxxxxxxxxxx> 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. Is it possible to find the code maintenance policy on a project site or somewhere? -- for both short run and long run. I may get some interest in using this tool for my debugging/testing/ self-educational porpuses, but cannot know what I can do/expect. Takuya For me, both QEMU and Native Linux KVM tool may be useful! :) But it is, probably I guess, for different porposes. > > I've looked at QEMU sources over the years and especially over the > past year and I think you might be way too familiar with its inner > workings to see how complex (even the core code) has become for > someone who isn't familiar with it. I think it has to do with lots of > indirection and code cleanliness issues (and I think that was the case > even before KVM came into the picture). So I don't agree at all that > taking QEMU as a starting point would make things any easier. (That > is, unless someone intimately familiar with QEMU does it.) -- Takuya Yoshikawa <yoshikawa.takuya@xxxxxxxxxxxxx> -- 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
