3G Eden
RSS一开始Yanming Zhang可能并不希望引起那场由一个补丁引发的激烈论战； 那个补丁往“perf”工具中增加了一系列KVM相关的命令。这个补丁的价值看似很明显：除了允许Host收集运行中的Guest的性能统计数据外，它还 使得将Host/Guest作为一个整体来进行剖析成为现实。人们可以想象一下其价值：通过它能够看到两个系统是怎样交互的。
问题是，这个特征似乎要求Host能够访问正在运行的KVM Guest的某些特定信息：至少，它需要Guest内核的符号表。更多的剖析操作还将需要访问Guest名称空间中的文件。为了达到该目的，Ingo Molnar建议说如果Host能够（只读地）挂载所有 Guest中活动的文件系统的话，事情会简单很多。他还说，如果Host可以很容易地枚举运行的Guest并且为其命名的话，效果也会相当不错。
但他得到的回应是“没门”。因为这样会带来许多的安全问 题，尽管Host上的文件系统不是全局可读的，也尽管最终在某种意义上Host是可以全权控制Guest的。当然还有一些非常有趣的问题，尤其是当 SELinux这样的框架也被搅进了浑水。但Ingo把这个回答视为一种不愿意与其他开发者协作以提高KVM，尤其是开发者的桌面系统可用性的声明。随之而来的是Ingo和KVM的开发者Avi Kivity之间那些时不时的尖酸刻薄而往复了n遍的讨论，这两方的支持者已经形成了一个小团体。
Ingo的态度是任何一个开发项目，如果想要成功的话，必须让那些贡献代码的用户更加方便。因此他说：系统应当对那些想在桌面上运行KVM的开发者更加友 好。此外，他还断言说长远看来，高度面向桌面对于长期的成功是相当重要的：
也就是说，内核可以通过提供一种明智的缺省配置来大大提高在各种情况下的质量（就ext3而言）——或者就perf而言，可以提供一种明智的基础工具。对于KVM来说我们也要这么做。
如果我们不这么做，Linux最后将会在桌面领域失去影响——然后在那之后不久，在服务器领域也会消失。十年之后，你将不会再有维护KVM的工作，甚至你都不知道消灭这个项目的力量是从哪里来的。
毫无疑问，Avi则对这些事情有着不同的看法：
事实上虚拟化就是用在数据中心而不是桌面上。你认为一个KVM的GUI会变成一个杀手级应用？好啊，写一个看看。你不需要征得任何我作为一个KVM维护者 的同意（如果改善桌面体验的KVM补丁是必需的，我会接受它们，虽然它们必须通过我那些不合理的微内核过滤器）。如果你是对的，那么KVM桌面GUI将会 有难以计数的开发者，同时会有很多人抛弃Windows并转换到Linux来使用它。
但我的看法是它会终结VirtualBox之类能够在Linux上跑Windows的好程序，但这并不是什么有用的事情。
Ingo的观点是没必要让用户都聚集到这个平台，真正重要的是吸引开发者。一个方便工作的KVM应该鼓励开发者自己来使用它，并进一步提高它的质 量。Anthony Liguori则指出VirtualBox 提供了更加绝妙的桌面体验，但并没有吸引大量的开发人员来解决它的性能问题。
让Ingo不爽的另一件事情是慢吞吞的改进，尤其是考虑到 QEMU这 个为Guest系统提供全系统环境的模拟器。他说，这儿问题的大部分原因是KVM和QEMU的分离，尽管他们是紧耦合的组件。Ingo还断言这种分离也正是拖累Xen的原因，而解决之道就是将 QEMU放进内核源码树：
如果你想跳跃到技术质量的另一个层次，你需要改正这种态度并回归到KVM的设计之初。着眼于Qemu（现在Qemu是最弱的地方），使之成为 KVM仓库的头号成员，并且通过使用单一仓库来简化开发模式。
从Ingo的观点看来，这种转变具有重大的意义。他说，KVM是QEMU项目最大的用户，在KVM出现之前QEMU甚至已经是奄奄一息了。通过同日发布的方式将这两个组件捆绑到一起，可以在接口的两边同时保证ABI正常工作。内核与用户控件的开发者可以在边界的两边改进代码。他还说，将perf引入内核树这件事情让外部开发者社区在不到一年 的时间内从一个提升到了超过60个。事实上，集成到内核树是为什么perf会获得成功的原因：
如果你对正在为perf工作的人的第一手经验感兴趣的话，可以给你看看：到现在为止，perf成功并可用的最大原因就是将用户空间的工具和内核 空间代码集成到了一个单一的仓库和工程。
显然，Ingo相信将QEMU集成到内核树也可以产生类似的效果。同样明显的是，KVM和QEMU的开发者不同意。对他们来说，这个提议就像是 QEMU开发的一个分叉——虽然KVM可以说已经在使用QEMU的一个分叉版本了。这种分叉，用Avi的话来说，“绝对是有害的”。而 根据Anthony的说法，将QEMU移入到内核树会加剧这种分叉：
如果我们将QEMU放入到Linux内核，我们会丢失大量的用户和贡献者。就像我以前说过的那样，大量的代码贡献来自不使用KVM的那些人。
KVM/QEMU的开发者不相信将代码移入内核树会得到更多的开发者，并且他们认为“内核开发者会制造出一个更加面向桌面的KVM”的说法是一个笑 话。他们并不将这种项目的分离看作是一个问题，并且在思考什么地方划定分界线最好。Avi建议说最终不属于内核的项目列表可能短一些更好。总的来说，他们 看到了一个不太可能损坏的系统——他们说QEMU正在快速地改进——而那些通过合并仓库的修正是得不到保证的。
这真是个好事情（tm）。它意味着你必须好好定义你的特征和接口，你可以独立地向前或向后命名版本号。同时，它会带来一些复杂 性和长时间的测试，但最后它将是你真正需要的东西。你不需要引入这个特征需求，你只需要直接享受它的优点。
Ingo对此又有不同看法，他依据的是他长时间的经验：
这是不可能的，相信我——在整个2.5.x系列开发中，我遭受了足够长时间的痛苦。我们一些最糟糕的ABI也来自哪个循环……同时你们也可以看到数不清的 例子，一份份仔细起草，充分考虑，集体编写的计算机标准，经过多年的磨砺，最终还不如书写它们的纸张那么值钱。
“多余的时间”和“多余的官僚式的全面考虑”是开发过程中最可恶的东西，应当杜绝。
随着讨论的渐渐落幕，看来很明显的是哪一边都没有取得让对方相信自己的进展。这意味着现状将会继续下去；如果KVM维护者没有兴趣作出改变，社区内的其他 人将很难压倒他们。这样的事情曾经发生过——x86和x86-64的合并就是一个经典的例子——但是用那样的方式压倒维护者需要社区内取得相当程度的共 识，目前看来这样的条件并不具备。如果不是这样，那就需要来自Linus的命令——但他在这场辩论中一直保持沉默。
因此最后结果看起来就是这样：
请考虑无限期废弃“perf kvm”吧，由于缺乏健壮的KVM测试功能：由于缺乏健壮的全局的vcpu/Guest枚举，由于在KVM这边缺乏健壮的全局的符号访问功能。我觉得它是 一个有前途的功能，因此我花了两天时间来争论，试图找到一种解决办法，但是没有找到。
这是否就是“perf kvm”的最终结局还有待继续观察；它的确是一个非常有用的功能并可能会找到一种方式进入内核。但现在KVM开发者和perf开发者之间的隔阂是将该功能合并到内核一个很明显的障碍。
来源：http://lwn.net/Articles/379869/
