为什么我需要在linux内核升级后重新编译vmware内核模块?

rIP*_*PER 5 linux vmware kernel module abi

在Linux内核升级之后,我的VMWare服务器无法启动,直到使用vmware-config.pl进行一些重新配置工作(包括构建一些内核模块).

如果我用最新的Windows Service Pack更新我的Windows VMWare主机,我通常不需要做任何事情来运行VMWare.

为什么VMWare在Linux和Windows之间的工作方式不同?这种重新编译操作是否会通过Windows在Linux平台上带来任何好处?

eph*_*ent 13

阅读Linux内核驱动程序接口.

编写本文是为了解释为什么Linux没有二进制内核接口,也没有稳定的内核接口.请注意,本文描述了_in kernel_接口,而不是用户空间接口的内核.内核到用户空间接口是应用程序使用的接口,即syscall接口.随着时间的推移,该接口是非常稳定的,并且不会破坏.我有一些基于0.9something内核的旧程序,在最新的2.6内核版本上仍能正常工作.该接口是用户和应用程序员可以指望稳定的接口.

它反映了大部分Linux内核开发人员的观点:随时更改内核实现细节和API的自由使他们能够更快更好地开发.

如果没有承诺在发行版之间保持内核接口相同,那么像VMWare这样的二进制内核模块就无法在多个内核上可靠地工作.

例如,如果某个结构在新内核版本上发生更改(为了获得更好的性能或更多功能或其他原因),二进制VMWare模块可能会使用旧的结构布局造成灾难性损坏.从源代码再次编译模块将捕获新的结构布局,因此更好的工作机会 - 尽管仍然不是100%,以防已删除或重命名字段或给出不同的目的.

如果函数更改其参数列表,或者重命名或以其他方式不再可用,则甚至不能从相同的源代码重新编译.该模块必须适应新内核.因为每个人(应该)都有源和(可以找到某人)能够修改它以适应."将工作推送到终端节点"是网络和自由软件中的一个常见想法:因为[在Linux内核以外的开发人员] [[边缘]/[资源]的资源大于[骨干]的有限资源/ [Linux开发人员],权衡使前者做更多的工作被接受.

另一方面,微软决定尽可能保持二进制驱动程序兼容性 - 他们别无选择,因为他们正在一个专有的世界中玩.在某种程度上,这使得不再面临移动目标的外部开发人员以及从不必更改任何内容的最终用户更容易.在不利方面,这迫使微软保持向后兼容性,这对微软的开发人员来说(充其量)是耗时的,并且(在最坏的情况下)效率低下,导致错误,并阻止前进.