mkubecek / vmware-host-modules

Patches needed to build VMware (Player and Workstation) host modules against recent kernels
GNU General Public License v2.0
2.25k stars 362 forks source link

[Question] Why doesn't vmware upstream these patches? #266

Open bogardon opened 1 month ago

bogardon commented 1 month ago

vmware/broadcom are still releasing new vmware versions for linux, but why don't they also patch their modules so it compiles on recent kernels? it seems weird that we're all relying on @mkubecek (god bless) to patch things time and time again.

what is the most recent kernel that vmware actually supports?

apologies if this has been answered before.

Manfred-Knick commented 1 month ago

VMware has never ever committed to anything like "the most recent (vanilla) kernel supported".

"Supported host operating systems ..." : https://knowledge.broadcom.com/external/article?legacyId=80807

For 17.5, evaluating the above list against www.kernel.org, I result into --> LTE 6.1 .

robertstrom commented 1 month ago

So how is it that VMware Workstation on Windows never seems to break through all of the monthly patching (of Windows) that happens in between releases of Workstation. Surely there are changes to the Windows kernel. Why does it almost always break on Linux, but not on Windows? Same with VMware Fusion. I have never seen it break like it does on Linux.

Manfred-Knick commented 1 month ago

Please, comprehend that VMware is primarily interested in making money by selling to commercial customers, exploiting co-operation with their Enterprise Partners. +++ FULL STOP +++

I suggest viewing VMware Workstation (and, formerly, Player) as supplemental to their expensive Enterprise solutions, providing some support for rather matured versions of open-source-distributions as exceptions supplemental to their respective enterprise counterparts.

With Microsoft as their outstanding Partner, their development departments will receive heavy-weighted assistance and advanced information support - which surely will not be disclosed to open-source projects: Heaven forbid!

Expecting benevolent permanent renewed support . - for open-source, . - for every new kernel version, . - for every common-or-garden distribution from VMware is simply naive. Such a commitment has never ever been granted: Perish the thought!

Much could be spared if this reality could finally be allowed to sink in.

Last not least, it is not only my personal impression that Broadcom seems primarily interested in enhancing the revenue out of their purchase.

ERGO:

Lots of us have been grateful for Michal Kubeček's mature patches against respective recent kernels.

The current massive hi-jacking of this repository with hundreds of half-baked mee-too-posts is not helpful at all: https://github.com/mkubecek/vmware-host-modules/issues/239#issuecomment-2132366980 .

I myself definitely refrain from deploying "solutions" not finally approved by an experienced kernel developer, particularly for productive use.

EDIT: Furthermore, for me, the late XZ backdoor debacle will persist as a strong reminder ... In 1135 a.C., although being warned by Laokoon ("quidquid id est, timeo Danaos et dona ferentes"), Trojans chose to learn that the hard way ...

rakotomandimby commented 1 month ago

@robertstrom , it is because Microsoft is more carrying about backward compatibility than the Linux kernel. One will always find an exception to what I just wrote, but community driven software can brake backward compatibility without notice. Windows cannot do that as freely as Linux.

Manfred-Knick commented 1 month ago

With all due respect: This proposition is misleading, at least, to put it mildly.

.- Linux kernel guarantees stability for its external programming API

. - -> Linus Torvalds: "We don't break user space!"

.- VMware exploits internal programming API calls, knowing that .- stability of internal programming API is not being guaranteed

.- Thus, when loading VMware modules, the kernel correctly qualifies itself as "tainted"

VMware nevertheless decided not to invest into keeping up with
development of internal calls being exploited in / for their (closed-source) application. Which is righteously their sovereignty.

"Supported ..." : The marks are clearly set.

" Love it - change it - or leave it "

mkubecek supported "change it" :-)