On 03/20/2010 04:59 PM, Andrea Arcangeli wrote:
On Fri, Mar 19, 2010 at 09:21:49AM +0200, Avi Kivity wrote:
On 03/19/2010 12:44 AM, Ingo Molnar wrote:
Too bad - there was heavy initial opposition to the arch/x86 unification as
well [and heavy opposition to tools/perf/ as well], still both worked out
extremely well :-)
Did you forget that arch/x86 was a merging of a code fork that happened
several years previously? Maybe that fork shouldn't have been done to
begin with.
We discussed and probably timidly tried to share the sharable
initially but we realized it was too time wasteful. In addition to
having to adapt the code to 64bit we would also had to constantly
solve another problem on top of it (see the various split on _32/_64,
those takes time to achieve, maybe not huge time but still definitely
some time and effort). Even in retrospect I am quite sure the way
x86-64 happened was optimal and if we would go back we would do it
again the exact same way even if the final object was to have a common
arch/x86 (and thankfully Linus is flexible and smart enough to realize
that code that isn't risking to destabilize anything shouldn't be
forced out just because it's not to a totally
theoretical-perfect-nitpicking-clean-state yet). It's still a lot of
work do the unification later as a separate task, but it's not like if
we did it immediately it would have been a lot less work. It's about
the same amount of effort and we were able to defer it for later and
decrease the time to market which surely has contributed to the
success of x86-64.
In hindsight decisions are much easier. I agree it was less risky to
fork than to share. But if another instruction set forks out a 64-bit
not-exactly-compatible variant, I'm sure we'll start out shared and not
fork it, especially if the platform remains the same.
Problem of qemu is not some lack of GUI or that it's not included in
the linux kernel git tree, the definitive problem is how to merge
qemu-kvm/kvm and qlx into it. If you (Avi) were the qemu maintainer I
am sure there wouldn't two trees so as a developer I would totally
love it, and I am sure that with you as maintainer it would have a
chance to move forward with qlx on desktop virtualization without
proposing to extend vnc instead to achieve a "similar" result (imagine
if btrfs is published on a website and people starts to discuss if it
should ever be merged ever because reinventing some part of btrfs
inside ext5 might achieve ""similar"" results).
The qemu/qemu-kvm fork is definitely hurting. Some history: when kvm
started out I pulled qemu for fast hacking and, much like arch/x86_64, I
couldn't destabilize qemu for something that was completely experimental
(and closed source at the time). Moreover, it wasn't clear if the qemu
community would be interested.
The qemu-kvm fork was designed for minimal intrusion so I could merge
upstream qemu regularly. This resulted in kvm integration that was
fairly ugly. Later Anthony merged a well-integrated alternative
implementation (in retrospect this was a mistake IMO - we were left with
a well tested high performing ugly implementation and a clean, slow,
untested, and unfeatured implementation, and no one who wants to merge
the two). So now it is pretty confusing to read the code which has the
two alternate implementation sometimes sharing code and sometimes diverging.
About a GUI for KVM to use on desktop distributions, that is an
irrelevant concern compared to the lack of protocol more efficient
than rdesktop/rdp/vnc for desktop virtualization. I've people asking
me to migrate hundreds of desktops to desktop virtualization on KVM in
their organizations and I tell them to use spice because I believe
it's the most efficient option available (at least as far as we stick
to open source open protocols), there are universities using spice on
thousand of student desktops, and I think we need paravirt graphics to
happen ASAP in the main qemu tree too.
That effort will have to wait for the spice project to mature.
In short: running KVM on the desktop is irrelevant compared to running
the desktop on KVM so I suggest to focus on what is more important
first ;).
Anyone can focus on what interests them, if someone has an interest in a
good desktop-on-desktop experience they should start hacking and sending
patches.
--
error compiling committee.c: too many arguments to function
--
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
