* Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> > > So, since we already have the lguest tool in the kernel tree,
> > > why cannot we have the much more capable tools/kvm/ in the
> > > tree?
> >
> > Lguest is in Documentation/ for a reason. It's not meant as a
> > user space tool that you take as-is and use. It's meant for
> > documenting how lguest works in general. I admit though, that
> > that's also the reason people don't use it :).
>
> I'd also say it's rather misplaced there, and at least in the
> storage area that I know most it didn't help it from totally
> misunderstanding kernel concepts and taking them into protocols
> (e.g. virtio barrier support). That for me is a reason why you
> don't want to couple thing too tightly, at least you'll have to
> document and/or explain the protocol to someone.
It's funny that you bring up ABIs and virtio, as in my experience
it's usually this pattern that creates bad ABIs in Linux:
1) there's an out of tree user-space project, written by a group of
developers, proposing some new feature for which they'd need
kernel help
2) they talk to another set of Linux kernel developers, who come up
with something that works - still out of tree
3) they then talk to upstream Linux and the whole review process
starts. The ABI changes in some minor ways but often survives.
4) nobody is risking any ABI changes because the distance from
upstream to the actual user-space project is 3 boundaries.
Whatever ad-hoc ABI was proposed initially is hammered through
if possible, unless it's 100% unworkable.
5) upstream often bends for pragmatic reasons, and it's at most
someone at the top of the maintenance hierarchy who says
'hell NO!' and forces an (expensive!) reiteration of all 5 steps.
I've also seen a couple of good ABIs, which had a very natural
development cycle:
1) developers working both upstream and in a user-space project
propose an ABI and quickly iterate through several versions. Both
the kernel side and the user-space side changes frequently and
iteratively to perfect the ABI and the whole process is highly
visible on lkml and gets review at every stage of this work.
Do you recognize what i'm trying to point out?
While moving a user-space tool project to tools/ certainly does not
*guarantee* good ABIs, it *does* guarantee friction-less iterations
of ABIs - which are much harder to achieve with out of tree projects.
We've done this numerous times for the perf ABI and while the ABI is
far from perfect it worked very well for us - far better than it
would have worked as a separate project.
In such an integrated tool/kernel tree bugs are also much easier to
debug: as we can cleanly bisect across interim versions of the ABI,
as the tools and the kernel side ABI is developed in lock-step. We do
not have to create cross-compatibility between every interim version
of the ABI and any future (or past) version of the tool ...
So yes, my first hand experience shows that you are 100% wrong:
- 'slow-play', out of tree, modularized, to-the-specification ABIs
tend to suck
- 'quickly iterated', in tree, unified, specified-on-lkml ABIs tend
to work out much better
There's exceptions, but that's the general trend.
Fact is that developing ABIs within an integrated project is
*amazingly* powerful. You should try it one day, instead of
criticizing it :-)
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
