The example was rcuifying kvm which took place a bit ago. Sorry, it
wasn't clear.
Correct. So should I tell someone that has sent a patch that rcu-ified
kvm in order to scale it, that I won't accept the patch unless they do
some usability userspace work? say, implementing an eject button.
That's what I understood you to mean.
That might hold, but the tool is usable at least for some people - it
runs in production. The people running it won't benefit from an eject
button or any usability improvement since they run it through a
centralized management tool that hides everything. They will benefit
from the scalability patches. Should I still make those patches
conditional on scalability work that is of no interest to the submitter?
kvm contains many sub-areas. I'm not going to tie unrelated things
together like the GUI and sclability, configuration file format and
emulator correctness, nested virtualization and qcow2 asynchronity, or
other crazy combinations. People either leave en mass or become
frustrated if they can't. I do reject patches touching a sub-area that
I think need to be done in userspace, for example.
That's not to say kvm development is random. We have a weekly
conference call where regular contributors and maintainers of both qemu
and kvm participate and where we decide where to focus. Sadly the issue
of a qemu GUI is not raised often. Perhaps you can participate and
voice your concerns.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
