为什么linux内核升级后需要重新编译vmware内核模块？
Linux 内核升级后，我的 VMWare 服务器无法启动，直到使用 vmware-config.pl 进行一些重新配置工作（包括构建一些内核模块）。
如果我使用最新的 Windows Service Pack 更新我的 Windows VMWare 主机，通常不需要执行任何操作即可运行 VMWare。
为什么 VMWare 在 Linux 和 Windows 上的工作方式不同？ 与 Windows 相比，这种重新编译操作在 Linux 平台上是否带来任何好处？
After a linux kernel upgrade, my VMWare server cannot start until using vmware-config.pl to do some re-config work (including build some kernel modules).
If I update my windows VMWare host with latest Windows Service Pack, I usually not need to do anything to run VMWare.
Why VMWare works differently between Linux and Windows? Does this re-compile action brings any benifits on Linux platform over Windows?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
请阅读Linux 内核驱动程序接口。
它反映了很大一部分Linux内核开发人员的观点：
随时更改内核实现细节和 API 的自由使他们能够更快更好地开发。
如果不承诺在各个版本之间保持内核接口相同，那么像 VMWare 这样的二进制内核模块就无法在多个内核上可靠地工作。
例如，如果新内核版本上的某些结构发生更改（为了更好的性能或更多功能或任何其他原因），则使用旧结构布局的二进制 VMWare 模块可能会导致灾难性损坏。 从源代码再次编译模块将捕获新的结构布局，从而有更好的工作机会——尽管仍然不是 100%，以防字段被删除或重命名或赋予不同的目的。
如果函数更改其参数列表，或者被重命名或以其他方式不再可用，则即使从相同的源代码重新编译也不起作用。 该模块必须适应新内核。 因为每个人（应该）都有源代码并且（可以找到能够修改它以适应的人）。 “将工作推送到终端节点”是网络和自由软件中的一个常见想法：因为[边缘]/[Linux 内核之外的开发人员]的资源大于[骨干]/的有限资源[Linux 开发人员]，让前者完成更多工作的权衡是可以接受的。
另一方面，微软已经决定他们必须尽可能地保留二进制驱动程序兼容性——他们别无选择，因为他们正在专有的世界中玩耍。 在某种程度上，这使得不再面临移动目标的外部开发人员以及永远不需要更改任何内容的最终用户变得更加容易。 不利的一面是，这迫使微软保持向后兼容性，这对于微软的开发人员来说（最好的情况下）是耗时的，（最坏的情况下）效率低下，会导致错误并阻碍向前发展。
Go read The Linux Kernel Driver Interface.
It reflects the view of a large portion of Linux kernel developers:
the freedom to change in-kernel implementation details and APIs at any time allows them to develop much faster and better.
Without the promise of keeping in-kernel interfaces identical from release to release, there is no way for a binary kernel module like VMWare's to work reliably on multiple kernels.
As an example, if some structures change on a new kernel release (for better performance or more features or whatever other reason), a binary VMWare module may cause catastrophic damage using the old structure layout. Compiling the module again from source will capture the new structure layout, and thus stand a better chance of working -- though still not 100%, in case fields have been removed or renamed or given different purposes.
If a function changes its argument list, or is renamed or otherwise made no longer available, not even recompiling from the same source code will work. The module will have to adapt to the new kernel. Since everybody (should) have source and (can find somebody who) is able to modify it to fit. "Push work to the end-nodes" is a common idea in both networking and free software: since the resources [at the fringes]/[of the developers outside the Linux kernel] are larger than the limited resources [of the backbone]/[of the Linux developers], the trade-off to make the former do more of the work is accepted.
On the other hand, Microsoft has made the decision that they must preserve binary driver compatibility as much as possible -- they have no choice, as they are playing in a proprietary world. In a way, this makes it much easier for outside developers who no longer face a moving target, and for end-users who never have to change anything. On the downside, this forces Microsoft to maintain backwards-compatibility, which is (at best) time-consuming for Microsoft's developers and (at worst) is inefficient, causes bugs, and prevents forward progress.
Linux 没有稳定的内核 ABI——数据结构的内部布局等随着版本的不同而变化。 VMWare 需要重建才能使用新内核中的 ABI。
另一方面，Windows 具有非常稳定的内核 ABI，不会因服务包而异。
Linux does not have a stable kernel ABI - things like the internal layout of datastructures, etc changes from version to version. VMWare needs to be rebuilt to use the ABI in the new kernel.
On the other hand, Windows has a very stable kernel ABI that does not change from service pack to service pack.
为了补充 bdonlan 的答案，ABI 兼容性是一个混合体。 一方面，它允许您分发可与较新版本的内核配合使用的二进制模块和驱动程序。 另一方面，它迫使内核程序员添加大量粘合代码以保持向后兼容性。 因为 Linux 是开源的，并且因为内核开发者即使他们被允许，分发二进制模块的能力并不被认为那么重要。 从好的方面来说，Linux 内核开发人员在更改数据结构以改进内核时不必担心 ABI 兼容性。 从长远来看，这会产生更干净的内核代码。
To add to bdonlan's answer, ABI compatibility is a mixed bag. On one hand, it allows you to distribute binary modules and drivers which will work with newer versions of the kernel. On the other hand, it forces kernel programmers to add a lot of glue code to retain backwards compatibility. Because Linux is open-source, and because kernel developers even whether they're even allowed, the ability to distribute binary modules isn't considered that important. On the upside, Linux kernel developers don't have to worry about ABI compatibility when altering datastructures to improve the kernel. In the long run, this results in cleaner kernel code.
这是 Linux 和 Windows 在不同的文化环境和期望中开发的结果： http://www.joelonsoftware .com/articles/Bicultureism.html。 简而言之：Windows 的设计目标是适合用户，而 Linux 的发展目标是适合开源开发人员。
It's a consequence of Linux and Windows being developed in different cultural environments and expectations: http://www.joelonsoftware.com/articles/Biculturalism.html. In short: Windows is designed to be suitable for users, whereas Linux evolves to be suitable for open source developers.