On Thu, 19 Sep 2013, Ingo Molnar wrote: > To solve all that make this change explicit, detectable and self-contained, > by iterating the ABI the following way: > > - Always clear bit 0, and rename it to usrpage->cap_bit0, to at least not > confuse old user-space binaries. RDPMC will be marked as unavailable > to old binaries but that's within the ABI, this is a capability bit. > > - Rename bit 1 to ->cap_bit0_is_deprecated and always set it to 1, so new > libraries can reliably detect that bit 0 is deprecated and perma-zero > without having to check the kernel version. > > - Use bits 2, 3, 4 for the newly defined, correct functionality: > > cap_user_rdpmc : 1, /* The RDPMC instruction can be used to read counts */ > cap_user_time : 1, /* The time_* fields are used */ > cap_user_time_zero : 1, /* The time_zero field is used */ > So let me think through the possible combinations: OLD-KERNEL OLD-HEADER + cap_usr_rdpmc and cap_usr_time map to the same bit + In general for kernels from 3.4 to 3.11 the bit will be set for all x86 NEW-KERNEL OLD-HEADER + cap_usr_rdpmc (cap_bit0) and cap_usr_time (cap_bit0) both are 0 + code detecting cap_usr_rdpmc will probably fall back to non-rdpmc even through rdpmc code is probably there and functioning OLD-KERNEL NEW-HEADER + cap_user_rdpmc and cap_user_time both set to 0 + cap_bit0_is_deprecated can be read; if it is 0 you can read cap_bit0, and if it is 1, assume rdpmc is available with the same likelyhood you could with the old header NEW-KERNEL NEW-HEADER + Use cap_user_rdpmc and cap_user_time and everything is OK > - Rename all the bitfield names in perf_event.h to be different from the > old names, to make sure it's not possible to mis-compile it > accidentally with old assumptions. Well this breaks that API, though I guess there are no guarantees there. I guess that's intentional since it will force users to fix their code, but a pain if you aren't expecting it and suddenly your project doesn't compile anymore after a kernel-headers update. Most of my code carries around its own perf_event.h so I guess I'll be unaffected. In any case this seems to be about as reasonable a solution to this problem as we can get. Vince -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html