Gavin Shan <gshan@xxxxxxxxxx> writes: > On 12/13/19 8:47 PM, Marc Zyngier wrote: >> On 2019-12-13 00:50, Gavin Shan wrote: >>> >>> Yeah, I think it is ABI change unfortunately, but I'm not sure how >>> many applications are using this filter. >> >> Nobody can tell. The problem is that someone will write a script that >> parses this trace point based on an older kernel release (such as >> what the distros are shipping today), and two years from now will >> shout at you (and me) for having broken their toy. >> > > Well, I would like to receive Vitaly's comments here. Vitaly, it seems it's > more realistic to fix the issue from kvm_stat side according to the comments > given by Marc? > Sure, if we decide to treat tracepoints as ABI then fixing users is likely the way to go. Personally, I think that we should have certain freedom with them and consider only tools which live in linux.git when making changes (and changing the tool to match in the same patch series is OK from this PoV, no need to support all possible versions of the tool). Also, we can be a bit more conservative and in this particular case instead of renaming fields just add 'exit_reason' to all architectures where it's missing. For ARM, 'esr_ec' will then stay with what it is and 'exit_reason' may contain something different (like the information why the guest exited actually). But I don't know much about ARM specifics and I'm not sure how feasible the suggestion would be. -- Vitaly
