Linux 内核升级后，我的 VMWare 服务器无法启动，直到使用 vmware-config.pl 进行一些重新配置工作(包括构建一些内核模块)。
如果我用最新的 Windows Service Pack 更新我的 Windows VMWare 主机，我通常不需要做任何事情来运行 VMWare。
为什么 VMWare 在 Linux 和 Windows 之间的工作方式不同？与 Windows 相比，此重新编译操作是否会在 Linux 平台上带来任何好处？
最佳答案
去读The Linux Kernel Driver Interface .
This is being written to try to explain why Linux does not have a binary kernel interface, nor does it have a stable kernel interface. Please realize that this article describes the _in kernel_ interfaces, not the kernel to userspace interfaces. The kernel to userspace interface is the one that application programs use, the syscall interface. That interface is _very_ stable over time, and will not break. I have old programs that were built on a pre 0.9something kernel that still works just fine on the latest 2.6 kernel release. This interface is the one that users and application programmers can count on being stable.
反射(reflect)了很大一部分Linux内核开发者的观点: 随时更改内核实现细节和 API 的自由使他们能够更快更好地开发。
如果不 promise 在不同版本之间保持内核接口(interface)相同，像 VMWare 这样的二进制内核模块就无法在多个内核上可靠地工作。
例如，如果某些结构在新内核版本上发生变化(为了更好的性能或更多功能或任何其他原因)，二进制 VMWare 模块可能会使用旧结构布局造成灾难性损坏。从源代码再次编译模块将捕获新的结构布局，因此有更好的工作机会——尽管仍然不是 100%，以防字段已被删除或重命名或被赋予不同的目的。
如果一个函数改变了它的参数列表，或者被重命名或以其他方式变得不再可用，即使从相同的源代码重新编译也不起作用。该模块将不得不适应新内核。因为每个人(应该)都有源代码并且(可以找到能够修改它以适应的人)。 “将工作推到终端节点”在网络和自由软件中都是一个普遍的想法:因为 [在边缘]/[Linux 内核之外的开发人员] 的资源大于 [主干]/的有限资源/[Linux 开发人员] 接受让前者做更多工作的权衡。
另一方面，Microsoft 已做出决定，他们必须尽可能保持二进制驱动程序的兼容性——他们别无选择，因为他们在专有世界中玩耍。在某种程度上，这使不再面对移动目标的外部开发人员以及永远不必更改任何内容的最终用户变得更加容易。不利的一面是，这迫使 Microsoft 保持向后兼容性，这对 Microsoft 的开发人员来说(充其量)是耗时的，而且(最坏的情况)效率低下，会导致错误并阻碍前进。
关于linux - 为什么我需要在 linux 内核升级后重新编译 vmware 内核模块？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/827862/