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.
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.)
On Fri, Apr 8, 2011 at 5:14 AM, Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote:
> Too much effort in QEMU goes into working around previous mistakes. That
> doesn't mean that QEMU doesn't have a lot of useful bits in it and hasn't
> figured out a lot of good ways to do things.
Completely agreed.
Pekka
--
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
