Ingo Molnar <mingo@xxxxxxx> writes: > [...] >> It's problem enough that there's no way to know what version of the >> perf_event abi you are running against and we have to guess based >> on kernel version. This gets "fun" because all of the vendors have >> backported seemingly random chunks of perf_event code to their >> older kernels. > > The ABI design allows for that kind of flexible extensibility, and > it's one of its major advantages. > > What we *cannot* protect against is you relying on obscure details of > the ABI [...] Is there some documentation that clearly spells out which parts of the perf syscall userspace ABI are "obscure" and thus presumably changeable? > [...] The usual ABI rules also apply: we'll revert everything that > breaks the ABI - but for that you need to report it *in time* [...] If the ABI is so great in its flexible extensibility, how come it can't be flexibly extended without having to passing the burden of compatibility testing & reversion-yawping to someone else? - FChE -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
