On 23/09/21 09:45, Marc Zyngier wrote:
On Thu, 23 Sep 2021 07:36:21 +0100,
Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
On 22/09/21 20:53, Marc Zyngier wrote:
I definitely regret adding the current KVM trace points, as they
don't show what I need, and I can't change them as they are ABI.
I disagree that they are ABI. And even if you don't want to change
them, you can always add parameters or remove them.
We'll have to agree to disagree here. Experience has told me that
anything that gets exposed to userspace has to stay forever. There are
countless examples of that on the arm64 side (cue the bogomips debate,
the recent /proc/interrupts repainting).
Files certainly have the problem that there are countless ways to parse
them, most of them wrong. This for example was taken into account when
designing the binary stats format, where it's clear that the only fixed
format (ABI) is the description of the stats themselves.
However yeah, you're right that what constitutes an API is complicated.
Tracepoints and binary stats make it trivial to add stuff (including
adding more info in the case of a tracepoint), but removing is tricky.
Another important aspect is whether there are at all any tools using the
tracepoints. In the case of the block subsystem there's blktrace, but
KVM doesn't have anything fancy (tracing is really only used by humans
via trace-cmd, or by kvmstat which doesn't care about which tracepoints
are there).
We had that discussion a few KSs ago (triggered by this[1] if I
remember correctly), and I don't think anything has changed since.
As for removing them, that would probably be best for some (if not
most) of them.
I'd say just go ahead. System calls are removed every now and then if
they are considered obsolete or a failed experiment. Tracepoints are in
the same boat.
Paolo
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
