[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git rep
From: |
Alexander Graf |
Subject: |
Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/ |
Date: |
Thu, 10 Nov 2011 02:41:53 +0100 |
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
- Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/, (continued)
- Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/, Anca Emanuel, 2011/11/10
- Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/, Gerd Hoffmann, 2011/11/10
- Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/, Ingo Molnar, 2011/11/08
- Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/, Ted Ts'o, 2011/11/08
- Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/, Anca Emanuel, 2011/11/08
- Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/, Ted Ts'o, 2011/11/08
- Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/, Ingo Molnar, 2011/11/09
- Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/, John Kacur, 2011/11/08
- Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/, Ingo Molnar, 2011/11/09
- Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/, Ingo Molnar, 2011/11/09
- Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/,
Alexander Graf <=
- Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/, Ingo Molnar, 2011/11/10
- Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/, Steven Rostedt, 2011/11/08
- Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/, Ingo Molnar, 2011/11/09
- Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/, Arnaldo Carvalho de Melo, 2011/11/09
- Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/, Américo Wang, 2011/11/09
- Re: [Qemu-devel] [F.A.Q.] the advantages of a shared tool/kernel Git repository, tools/perf/ and tools/kvm/, Ingo Molnar, 2011/11/10
- Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels, Kevin Wolf, 2011/11/07
- Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels, Pekka Enberg, 2011/11/07
- Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels, Kevin Wolf, 2011/11/07
- Re: [Qemu-devel] [PATCH] KVM: Add wrapper script around QEMU to test kernels, Jan Kiszka, 2011/11/06