Posted Sep 25, 2013 4:18 UTC (Wed) by iabervon (subscriber, #722)
Parent article: A perf ABI fix
Reading the old code, it looks like bit 0 was *actually* true if either capability was available. So you could leave bit 0 with that behavior, have bit 1 indicate one capability and bit 2 indicate the other. Then you've got the following properties:
Old binary, new kernel: same as old kernel, buggy but not a regression.
New binary, new kernel: works correctly.
New binary, old kernel, no code change: doesn't use either feature, but the system might not have whichever feature you're actually interested in, so it's safer.
New binary, old kernel, extra code: if bit 0 is set, but neither other bit is set, you know that the info is unreliable; if bit 0 is not set, you know the system has neither feature.
The only possible regression is that a new build with only the old API and an old kernel, which explicitly tests for a feature, would no longer have its test subverted; it would no longer use a feature that might happen to work when there's no way to tell.
If you interpret the old ABI as "kernel will only set the bit if it is definitely making the feature available", this wouldn't be an ABI change, in that the new code would conform to that ABI at least as well as the old code did.