On 03/22/2010 06:32 PM, Ingo Molnar wrote:
So, what do you think creates code communities and keeps them alive?
Developers and code. And the wellbeing of developers are primarily influenced
by the repository structure and by the development/maintenance process - i.e.
by the 'fun' aspect. (i'm simplifying things there but that's the crux of it.)
There is nothing fun about having one repository or two. Who cares
about this anyway?
tools/kvm/ probably will draw developers, simply because of the glory
associated with kernel work. That's a bug, not a feature. It means
that effort is not distributed according to how it's needed, but because
of irrelevant considerations.
I simply do not want to see KVM face the same fate, and yes i do see similar
warnings signs.
The number of kvm and qemu developers keeps increasing.
We're having a kvm forum in August where we all meet. Come and see for
yourself.
We actually have lguest which is small. But it lacks functionality and the
developer community KVM has attracted.
I suggested long ago to merge lguest into KVM to cover non-VMX/non-SVM
execution.
Rusty posted some initial patches for pv-only kvm but he lost interest
before they were completed. No one followed up.
btw, lguest has a single repository, userspace and kernel in the same
repository, yet is practically dead.
I think you are rationalizing the status quo.
I see that there are issues with KVM today in some areas. You pointed out
the desktop usability already. I personally have trouble with the
qem-kvm.git because it is unbisectable. But repository unification doesn't
solve the problem here.
Why doesnt it solve the bisectability problem? The kernel repo is supposed to
be bisectable so that problem would be solved.
These days qemu-kvm.git is bisectable (though not always trivially).
qemu.git doesn't have this problem.
The point for a single repository is that it simplifies the development
process. I agree with you here. But the current process of KVM is not too
difficult after all. I don't have to touch qemu sources for most of my work
on KVM.
In my judgement you'd have to do that more frequently, if KVM was properly
weighting its priorities. For example regarding this recent KVM commit of
yours:
| commit ec1ff79084fccdae0dca9b04b89dcdf3235bbfa1
| Author: Joerg Roedel<joerg.roedel@xxxxxxx>
| Date: Fri Oct 9 16:08:31 2009 +0200
|
| KVM: SVM: Add tracepoint for invlpga instruction
|
| This patch adds a tracepoint for the event that the guest
| executed the INVLPGA instruction.
With integrated KVM tooling i might have insisted for that new tracepoint to
be available to users as well via some more meaningful tooling than just a
pure tracepoint.
Something I've wanted for a long time is to port kvm_stat to use
tracepoints instead of the home-grown instrumentation. But that is
unrelated to this new tracepoint. Other than that we're satisfied with
ftrace.
You should realize that naturally developers will gravitate towards the most
'fun' aspects of a project. It is the task of the maintainer to keep the
balance between fun and utility, bugs and features, quality and code-rot.
There are plenty of un-fun tasks (like fixing bugs and providing RAS
features) that we're doing. We don't do this for fun but to satisfy our
users.
--
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
