lkml.org 
[lkml]   [2011]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ANNOUNCE] Native Linux KVM tool
Hi!

> Hi Anthony,
>
> On Fri, Apr 8, 2011 at 5:14 AM, Anthony Liguori <anthony@codemonkey.ws> 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@oss.ntt.co.jp>


\
 
 \ /
  Last update: 2011-04-08 09:13    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site