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    [W:0.023 / U:0.076 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site