* Avi Kivity<avi@xxxxxxxxxx> wrote:
On 03/22/2010 06:32 PM, Ingo Molnar wrote:And yet your solution to that is to ... do all your work in the kernel space
So, what do you think creates code communities and keeps them alive?There is nothing fun about having one repository or two. Who cares about
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.)
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.
and declare the tooling as something that does not interest you? ;-)
Something I've wanted for a long time is to port kvm_stat to use tracepointsDespite it being another in-kernel subsystem that by your earlier arguments
instead of the home-grown instrumentation. But that is unrelated to this
new tracepoint. Other than that we're satisfied with ftrace.
should be done via a user-space package? ;-)
So which one is it, KVM developers are volunteers that do fun stuff and cannotYou should realize that naturally developers will gravitate towards theThere are plenty of un-fun tasks (like fixing bugs and providing RAS
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.
features) that we're doing. We don't do this for fun but to satisfy our
users.
be told about project priorities, or KVM developers are pros who do unfun
stuff because they can be told about priorities?
I posit that it's both: and that priorities can be communicated - if only you
try as a maintainer. All i'm suggesting is to add 'usable, unified user-space'
to the list of unfun priorities, because it's possible and because it matters.