On 7/31/20 2:44 AM, Markus Armbruster wrote:
Thread_id should be optional and thus not filled in if we
can't provide a sensible value. Unfortunately we made it
mandatory in QMP.
Normally, converting a mandatory output value to optional is a
back-compatibility risk (we could break apps that depended on it being
present). But if the only apps that depended on it being present are
compiled on Linux, where the member will actually be present, I think
that changing the schema to make it optional for non-Linux platforms
won't be a back-compatibility nightmare (but we will have to be
careful in our documentation).
Options for systems where don't know how to compute a system-wide thread
ID:
0. Return a bogus value: the PID. This is the status quo.
1. Return a more obviously bogus value: -1. Semantic compatibility
break. Should be harmless, because a QMP client relying on the
thread-id being the PID would be insane.
2. Make thread-id optional, present iff we can compute a value.
This is what we should have done, but we didn't, and now it's a
syntactic compatibility break. Matters only if it actually breaks
QMP clients. We believe the one we know shouldn't break.
Preferences?
I'm in favor of 2, but can easily live with 1 if we decide to be that
much more conservative. Tooling that can't handle a missing value is
not going to fare any better with a value that is unusable because it is
-1, but the important point is that I don't think we have a scenario
with such tooling depending on the value (the tools that DO depend on
the value are built on platforms where the value is usable).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
