Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/

[Alexander Graf]

On 09.11.2011, at 09:23, Ingo Molnar wrote:

> 
> * Ted Ts'o <address@hidden> wrote:
> 
>> On Tue, Nov 08, 2011 at 01:55:09PM +0100, Ingo Molnar wrote:
>> 
>>> I guess you can do well with a split project as well - my main 
>>> claim is that good compatibility comes *naturally* with 
>>> integration.
>> 
>> Here I have to disagree; my main worry is that integration makes it 
>> *naturally* easy for people to skip the hard work needed to keep a 
>> stable kernel/userspace interface.
> 
> There's two observations i have:
> 

[...]

> I don't think your argument makes much sense: how come Linux, a 15 
> MLOC monster project running for 20 years has not been destroyed by 
> the "lack of the safety valve" problem? Why would adding the at most 
> 1 MLOC deeply kernel related Linux tool and library space to the 
> kernel repo affect the dynamics negatively? We added more code to the 
> kernel last year alone.
> 
> Fact is, competition thrives within the Linux kernel as well. Why is 
> a coherent, unified, focused project management an impediment to a 
> good technological result? Especially when it comes to desktop 
> computers / tablets / smartphones, where having a unified project is 
> a *must*, so extreme are the requirements of users to get a coherent 
> experience.
> 
> Think about this plain fact: there's not a single successful 
> smartphone OS on the market that does not have unified project 
> management. Yes, correlation is not causation and such, but still, 
> think about it for a moment.

I see your arguments and I think others do too. Look at the BSD or Solaris 
guys. Heck, even Windows and Mac OS have a lot tighter user-space and kernel 
bindings than we do.

However I don't see any real reason for us who already have the strong syscall 
ABI boundary as border defined to change that anytime soon. So far it's worked 
out pretty well IMHO.

But yes, if you were to push things from the bottom up, it would even make 
sense. If you were to push glibc into the kernel it would make sense. I maybe 
still wouldn't agree with it, but it'd at least be logical, because that's the 
next layer from the kernel's point of view.

If you were to push busybox into the kernel, it would also make sense, so that 
you can have a fully self-contained system that doesn't need external 
dependencies built inside a single tree. Again, I wouldn't agree on it because 
I like user space to be multi platform, but I could see the point. The same 
goes for udev and systemd.

For kvm tool however, I don't. It's very very high up the stack. In fact, I 
can't imagine too many applications being too much higher up the stack than a 
VM monitor. It needs to talk to the user (gtk?). It needs to talk to the 
network (which might be implemented using vde). It needs to talk to storage 
(which could be hidden behind user space libraries). It basically is a consumer 
of all the interfaces we provide 50 layers above the kernel.

So I find the comparison of pulling GNOME3 and KVM Tool into the kernel fair. 
Both depend on about the same amount of user space. And even though KVM Tool 
might not depend on all that much today, I'm sure you guys don't want to limit 
yourselves in scope just because you're "in the kernel tree".

Outside of the kernel tree, you can do your own decisions. If someone thinks 
it's a great idea to write device emulation in python (I would love that!), he 
could go in and implement it without having to worry about Linus possibly 
rejecting it because it's out of scope for a "Linux kernel testing tool". If 
you want to create the greatest GUI for virtualization the world has ever seen, 
you can just do it! Nothing holds you back.

You already have a very thriving development community. There are active 
contributers all over the place in KVM Tool. People already are interested in 
it. Why do you want to be in the kernel tree so badly? I honestly think it 
would rather hurt the project rather than help it.

So in all honesty, I wish for a KVM Tool outside of the kernel tree so it can 
thrive and evolve into something great - without artificial borders. And I'm 
sure most of the KVM Tool developers wish for the thriving part as well - which 
I believe can not happen inside the kernel tree.


Alex