在Linux内核升级之后,我的VMWare服务器无法启动,直到使用vmware-config.pl进行一些重新配置工作(包括构建一些内核模块).
如果我用最新的Windows Service Pack更新我的Windows VMWare主机,我通常不需要做任何事情来运行VMWare.
为什么VMWare在Linux和Windows之间的工作方式不同？这种重新编译操作是否会通过Windows在Linux平台上带来任何好处？
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.
它反映了大部分Linux内核开发人员的观点：
随时改变内核实现细节和API的自由使他们能够更快更好地开发.
如果没有承诺在发行版之间保持内核接口相同,那么像VMWare这样的二进制内核模块就无法在多个内核上可靠地工作.
例如,如果某个结构在新内核版本上发生更改(为了获得更好的性能或更多功能或其他原因),二进制VMWare模块可能会使用旧的结构布局造成灾难性损坏.从源代码再次编译模块将捕获新的结构布局,因此更好的工作机会 – 尽管仍然不是100％,以防已删除或重命名字段或给出不同的目的.
如果函数更改其参数列表,或者重命名或以其他方式不再可用,则甚至不能从相同的源代码重新编译.该模块必须适应新内核.因为每个人(应该)都有源和(可以找到某人)能够修改它以适应. “将工作推送到终端节点”是网络和自由软件中的一个常见想法：因为[在Linux内核以外的开发人员] [[边缘] / [资源]的资源大于[骨干]的有限资源/ [Linux开发人员],权衡使前者做更多的工作被接受.
另一方面,微软决定尽可能保持二进制驱动程序兼容性 – 他们别无选择,因为他们正在一个专有的世界中玩.在某种程度上,这使得不再面临移动目标的外部开发人员以及从不必更改任何内容的最终用户更容易.在不利方面,这迫使微软保持向后兼容性,这对微软的开发人员来说(充其量)是耗时的,并且(在最坏的情况下)效率低下,导致错误,并阻止前进.
