On Fri, Jul 31, 2020 at 08:46:40AM -0500, Eric Blake wrote: > 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).
I'm fine with (2) too. While technically a backcompat break, it won't hurt us in the real world, and so is the pragmatic choice that gets us to a long term better solution. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
