* Frank Ch. Eigler <fche@xxxxxxxxxx> wrote: > Frederic Weisbecker <fweisbec@xxxxxxxxx> writes: > > > [...] It is actually because both kernel and user side are sync in this > > scheme. [...] > > This argues that co-evolution of an interface is easiest on the developers > if they own both sides of that interface. No quarrel. Correct, that's a big advantage. > This does not argue that that the preservation of a stable ABI is best done > this way. If anything, it makes it too easy to change both the provider and > the preferred user of the interface without noticing unintentional breakage > to forlorn out-of-your-tree clients. Your concern is valid, and this issue has been raised in the past as one of the main counter-arguments against tools/perf/. (there was a big flamewar about it on lkml when it was introduced) Our roughly 1 year experience with perf is that, somewhat pradoxially, this scheme not only works as well as classic ABI schemes but actually brings a _better_ ABI than the classic "let the kernel define an ABI" single-sided solution. I know the difference first hand, i've written various syscalls ABIs in the past 10+ years before perf and know how they interact with their user space counterparts. Why did it work out better with tools/perf/? It turns out that there's an immediate, direct, actionable test feedback effect on the ABI, and much closer relation to the ABI. Typically the same developer implements the kernel bits and the user-space bits (because it's so easy to do co-development), so the ABI aspects are ingrained in the developer much more deeply. Once you see the kind of havoc ABI breakage can cause during development you avoid it in the future. So developers find that a good, stable ABI helps development. It turns out that developers dont actually _want_ to break the ABI and are careful about it - and having the app next to the kernel ABI and co-developing it makes it sure there's never any true mismatch. Also, we can do ABI improvements at a far higher rate than any other kernel subsystem. I checked the git logs, we've done over three dozen ABI extensions since the first version, and all were forwards _and_ backwards compatible. A higher rate of change gives developers more experience and lets them do a better ABI, and makes them more ABI-conscious. I think if all kernel ABIs had such a healthy rate of change we'd fill in all the missing kernel features very quickly. With detached packages ABI features are often done by a kernel developer (who is familar with the kernel subsystem in question) and a separate user-space developer (who is familar with the user-space project in question), and the ABI consciousness is less strong. So you are right that there's a danger of accidental ABI breakage, but it's not an issue in practice. There are external apps making use of the ABI as well, not just tools/perf/. In a more abstract sense this is kind of a classic case of game theory: that a assume-trust strategy pays off in the long run. Thanks, Ingo -- 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
