Question

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?

Answer 1

Go read 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.

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.