Erm, my usability points are _doubly_ true when there are multiple guests ...
The inconvenience of having to type:
perf kvm --host --guest --guestkallsyms=/home/ymzhang/guest/kallsyms \
--guestmodules=/home/ymzhang/guest/modules top
is very obvious even with a single guest. Now multiply that by more guests ...
The crux is: we are working on improving KVM instrumentation. There are
working patches posted to this thread and we would like to have/implement an
automatism to allow the discovery of all this information. The information
should be available to the developer who wants it, and easily/transparently so
- in true Linux fashion.
You havent articulated an actionable reason and you have suggested no solution
either, you just passive-agressive backed the claim that giving developers
access to the symbol space is some sort of vague 'security threat'.
If that is not so i'd be glad to be proven wrong.
That is the crux of the matter. My experience in these threads was that no-one
really seems to feel in charge of the whole thing. Should we really wonder why
KVM usability sucks?
This is one of the weirdest arguments i've seen in this thread. Almost all the
time do we make contributions conditional on the general shape of the project.
Developers dont get to do just the fun stuff.
This is a basic quid pro quo: new features introduce risks and create
additional workload not just to the originating developer but on the rest of
the community as well. You should check how Linus has pulled new features in
the past 15 years: he very much requires the existing code to first be
top-notch before he accepts new features for a given area of functionality.
Doing that and insisting on developers to see those imbalances as well is
absolutely essential to code quality: otherwise everyone would be running
around implementing just the features they are interested in, without regard
for the general health of the project.
Of course, if you keep the project in two halves (KVM and Qemu), and pretend
that they are separate and have little relation, imbalances of quality can
mount up and you can throw your hands up and say that it's "too bad, I'm not
maintaining that". It is your basic duty as a Linux maintainer to keep
balances of quality. I do it all day, other maintainers do it all day.
No, my suggestion to you (it's up to you whether you give my opinion any
weight) is to accept your mistakes and improve, and to not stand in the way of
people who'd like to improve the situation. You are happy with the server
features and you also made it clear that you dont feel responsible for the
rest of the package - which is a big mistake IMO.
Also, you have demonstrated it in this thread that you have near zero
technical clue about basic desktop and development usability matters - for
example your stance on symbol space access and your stance on how to enumerate
guests symbolically are outright bizarre.
Thanks,
Ingo
--
