VMware 12.1.1 and 4.7.0-1

VMware 12.1.1 and 4.7.0-1 [openSUSE Tumbleweed (20160730) (x86_64)]:

1. VMware Virtual ethernet module:

/usr/lib/vmware/modules/source/vmnet-only/netif.c: In function ‘VNetNetifStartXmit’:
/usr/lib/vmware/modules/source/vmnet-only/netif.c:468:7: error: ‘struct net_device’ has no member named ‘trans_start’; did you mean ‘mem_start’?
    dev->trans_start = jiffies;
       ^~

Robert Gadsdon’s solution was to remove that line entirely:
http://rglinuxtech.com/?p=1746

Also virtualbox developers did basically the same:
https://www.virtualbox.org/ticket/15444
https://www.virtualbox.org/changeset/61429/vbox

VMware and 4.6.1-1

Today while trying to compile kernel modules for VMware Workstation 12.1.1 + 4.6.1-1-default [openSUSE Tumbleweed (20160422) (x86_64)] I got two compilation errors:

1. VMware Virtual ethernet module:

/usr/lib/vmware/modules/source/vmnet-only/userif.c:116:13: error: too many arguments to function ‘get_user_pages’
    retval = get_user_pages(current, current->mm, addr,
             ^

2. VMware Virtual machine monitor:

/usr/lib/vmware/modules/source/vmmon-only/linux/hostif.c:1165:13: error: too many arguments to function ‘get_user_pages’
    retval = get_user_pages(current, current->mm, (unsigned long)uvAddr,
             ^

VMware Community member alexsandr1981 has the correct answer in the discussion, which is to replace every get_user_pages call with get_user_pages_remote calls.
After replacing the original tar, the compilation succeeded for me.

Bash Compatibility

Recently, I had to rebase a pack of bash scripts, and the new baseline used new platform with a somewhat newer bash version.

The biggest impact on our codebase was a “tiny” change in the behaviour of pattern matching. Let’s look at the bash manual on Conditional-Constructs :

“An additional binary operator, ‘=~’, is available, … When it is used, the string to the right of the operator is considered an extended regular expression and matched accordingly… “

OK, that’s fine, this has been the same since ages, and that’s what we used so far, but read further, here comes the new stuff:

Any part of the pattern may be quoted to force it to be matched as a string.

Now that’s an issue, because so far there were no exception, and we used quote as a delimiter…
The code below “works” on bash 3.1 but “doesn’t work” on any later version, unless you remove the comment from the second line.

#!/bin/bash
#shopt -s compat31

content="./170/0"

if [[ "${content}" =~ "\./[0-9]{1,3}/[0-9]{1,3}" ]]
then
    echo "works";
else
    echo "doesn't work";
fi

To the available compatibility modes on your system depends on your bash version, use shopt to check it:

ferenc@linux-spa2:~> shopt -p | grep compat
shopt -u compat31
shopt -u compat32
shopt -u compat40
shopt -u compat41
ferenc@linux-spa2:~>

For further info check the bash manual on shopt. And here is a link to the accumulated changelogs of all the bash versions.