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

[Ingo Molnar]

* 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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/