mkubecek
Add support for Workstation 17.6.3
Very very minor changes to some of the RHEL support macros. This works with 6.13.x and 6.14.x kernels.
Edit: Updated with support for 6.15.x and 6.16.x
Edit: 17.6.4 is identical.
Edit: Kernel 6.17.x doesn't require any additional changes (surprise!)
I still get the compilation error
vmmon.o: warning: objtool: CrossPage_CodePage+0x1d6: corrupt function pointer reference
With the 6.13.9-200.fc41.x86_64 kernel. In fact I've been getting that corrupt function pointer reference problem with earlier kernels as well but I didn't track them. Can anyone else reproduce this using this branch?
Worked great in Fedora 42 with kernel 6.15.3-200.fc42.x86_64 without errors! Thanks!
Hello. I probably did something wrong, but when I apply this, my VM network will stop working. Archlinux latest 6.15.4-arch2-1.1
@zDEFz Does VM network work fine when you use https://github.com/mkubecek/vmware-host-modules/issues/306#issuecomment-2843789954 ?
Edit:
For me the modules in the linked .tar.gz file worked, after sudo systemctl restart vmware
@zDEFz Does VM network work fine when you use #306 (comment) ?
Edit: For me the modules in the linked .tar.gz file worked, after
sudo systemctl restart vmware
Sorry, but I think this is a displaced question. I won't blindly use the .tar.gz I did once, and that was an absolute exception. Expecting a PR, then will test.
Well, I asked so that we can better pinpoint if there is an issue in this PR, or in your setup in general.
Also about reviewability / transparency about made changes, I feel like a PR with 76k LOC change (like this one) is not much better, optimally we'd have a PR that just shows the diff (what changes needed to be done so it compiles) or am I missing something?
I feel like a PR with 76k LOC change (like this one) is not much better
I just see, that @philipl did something that leads to the actual changes he made to be shown at the bottom of the commit history.
I made a branch from the changes of @jeamieofqidan for 6.15 here: https://github.com/powellnorma/vmware-host-modules/commits/workstation-17.6.3_jeamieofqidan/
I feel like a PR with 76k LOC change (like this one) is not much better
I just see, that @philipl did something that leads to the actual changes he made to be shown at the bottom of the commit history.
I made a branch from the changes of @jeamieofqidan for 6.15 here: https://github.com/powellnorma/vmware-host-modules/commits/workstation-17.6.3_jeamieofqidan/
How does that differ from the version that works from kernel 6.16?
This PR is structured to create a branch for 17.6 that follows the pattern used for creating branches for older releases. As a result it's not going to be just the changes required to fix compilation. If you look at the source branch for the PR itself, the history is clear.
How does that differ from the version that works from kernel 6.16?
You'd need to take the tgz for 6.16 and overwrite all files, then commit the changes. This way you'd get a commit which contains the diff, to see what jeamieofqidan changed for 6.16 compatibility. I might do this later if I find the time for it.
This PR is structured to create a branch for 17.6 that follows the pattern used for creating branches for older releases. As a result it's not going to be just the changes required to fix compilation
But why the latest commits show up as first commits? It does not make intuitive sense. I think it should be possible to add your newer commits afterward, not before. Why is it done this way?
But why the latest commits show up as first commits? It does not make intuitive sense. I think it should be possible to add your newer commits afterward, not before. Why is it done this way?
I don't know what you mean. github decides how to show the commits in a PR, but they are in ascending order on my screen, with the newest commits at the bottom of the list.
But why the latest commits show up as first commits? It does not make intuitive sense. I think it should be possible to add your newer commits afterward, not before. Why is it done this way?
I don't know what you mean. github decides how to show the commits in a PR, but they are in ascending order on my screen, with the newest commits at the bottom of the list.
not for me. what do you see?
That screenshot isn't from this PR's commit list, so I don't know what you're looking at.
That screenshot isn't from this PR's commit list, so I don't know what you're looking at.
It's from the link that was posted https://github.com/powellnorma/vmware-host-modules/commits/workstation-17.6.3_jeamieofqidan/
What link did you visit?
The commits for this PR. That we are adding comments to.
The link you are referring to is the commit list for a branch, and github shows a branch's commit history in descending order with the most recent first. That's normal git behaviour.
This PR is structured to create a branch for 17.6 that follows the pattern used for creating branches for older releases. As a result it's not going to be just the changes required to fix compilation
But why the latest commits show up as first commits?
What I meant were the oldest commits, I got confused why they were shown at the beginning of the PR commit history. But now I see it is probably just GH using different ordering for "branch commit history" and "PR commit history".
For new PRs, GH seems to by default base them off from the repos master branch. I think it would make sense to make it such that master points to the latest commit/branch. This way the PR should show nicer. But that's not something @philipl can influence, ofc. @mkubecek would need to decide on that.
What one can do as contributor though, is to chose as base branch the latest available one, instead of master. Example: https://github.com/mkubecek/vmware-host-modules/pull/316
Updated - works and tested. Thanks @philipl https://aur.archlinux.org/packages/vmware-host-modules-dkms-fix-git