Re: [RFC] Unify KVM kernel-space and user-space code into a single project

Ingo Molnar
2010-03-18T20:47:10Z

* Frank Ch. Eigler <fche@redhat.com> wrote:

> Frederic Weisbecker <fweisbec@gmail.com> 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