* Avi Kivity<avi@xxxxxxxxxx> wrote:
[ Sidenote: i still received no adequate suggestions about how to provide thisThe crux of the problem is very simple. To quote my earlier mail:
|
| - 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 ...
|
For example we want 'perf kvm top' to do something useful by default: it
should find the first guest running and it should report its profile.
The tool shouldnt have to guess about where the guests are, what their
namespaces is and how to talk to them. We also want easy symbolic access to
guest, for example:
perf kvm -g OpenSuse-2 record sleep 1
category of technical features. ]
That's weird, how can a feature request be a 'layering violation'?I.e.:Usually 'layering violation' is trotted out at such suggestions.
- Easy default reference to guest instances, and a way for tools to
reference them symbolically as well in the multi-guest case. Preferably
something trustable and kernel-provided - not some indirect information
like a PID file created by libvirt-manager or so.
[...]
If something that users find straightforward and usable is a layering
violation to you (such as easily being able to access their own files on the
host as well ...) then i think you need to revisit the definition of that term
instead of trying to fix the user.
[...] I don't like using the term, because sometimes the layers are
incorrect and need to be violated. But it should be done explicitly, not as
a shortcut for a minor feature (and profiling is a minor feature, most users
will never use it, especially guest-from-host).
The fact is we have well defined layers today, kvm virtualizes the cpu and
memory, qemu emulates devices for a single guest, libvirt manages guests.
We break this sometimes but there has to be a good reason. So perf needs to
talk to libvirt if it wants names. Could be done via linking, or can be
done using a pluging libvirt drops into perf.
You simply kept ignoring me when I said that if something can be kept out ofI never suggested an "in kernel space symbol server" which could oops, why
the kernel without impacting performance, it should be. I don't want
emergency patches closing some security hole or oops in a kernel symbol
server.
would i have suggested that? Please point me to an email where i suggested
that.
The usability argument is a red herring. True, it takes time for things toIt's not just "download and compile", it's also "configure correctly for
trickle down to distributions and users. Those who can't wait can download
the code and compile, it isn't that difficult.
several separate major distributions" and "configure to per guest instance
local rules".
It's far more fragile in practice than you make it appear to be, and since you
yourself expressed that you are not interested much in the tooling side, how
can you have adequate experience to judge such matters?
In fact for instrumentation it's beyond a critical threshold of fragility -
instrumentation above all needs to be accessible, transparent and robust.
If you cannot see the advantages of a properly integrated solution then i
suspect there's not much i can do to convince you.
And you ignored not just me but you ignored several people in this thread who
thought the current status quo was inadequate and expressed interest in both
the VFS integration and in the guest enumeration features.