Re: [ANNOUNCE] Native Linux KVM tool

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/06/2011 04:33 AM, Ingo Molnar wrote:
* Avi Kivity<avi@xxxxxxxxxx>  wrote:

Sure, any succcesful project becomes an ugly gooball.  It's almost a
compliment.
I disagree strongly with that sentiment and there's several good counter
examples:

  - the Git project is also highly successful and is kept very clean (and has a
    project size comparable to Qemu)

  - the Linux kernel is also very clean in all areas i care about and has most
    of its ugliness stuffed into drivers/staging/ (and has a project size more
    than an order of magnitude larger than Qemu).

In fact i claim the exact opposite: certain types of projects can only grow
beyond a certain size and stay healthy if they are *not* ugly gooballs.

Examples: X11 and GCC - both were struggling for years to break through magic
invisible barriers of growth and IMHO a lot of it had to do with the lack of
code (and development model) cleanliness.

So what makes Native Linux KVM tool so much cleaner?

As far as I can tell, it's architecturally identical to QEMU. In fact, it's reminiscent of QEMU from about 5 years ago. It makes the same mistakes of having a linear I/O dispatch model, makes no attempt to enable a threaded execution model, ignores thing like migration and manageability.

So no, your kind of cynical, defeatist sentiment about code quality is by no
means true in my experience. Projects become ugly gooballs once maintainers
stop caring enough.

It think sweeping generalizations are always wrong :-)

I struggle with a lot of things in QEMU. Compatibility is just a nightmare to maintain because so many of the previous interfaces and functionality were so poorly thought through.

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.

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.

Regards,

Anthony Liguori

Thanks,

	Ingo

--
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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux