It's a feature that makes the kernel to lie to old userspace programs that insist on only supporting Linux 2.6.
By calling personality(2) with PER_LINUX | UNAME26, uname(2) will from then on pretend that you're actually running linux 2.6.something.
This is meant as a workaround for software you don't have the source code to and which does some crazy checks for the version, assuming it doesn't support anything but 2.6.
Here's the source of a little wrapper utility you can use to invoke such broken software with:
The switch from 2.4 to 2.6 had a lot of changes and a lot of programs needed to check the version to see which behavior to use. There are two ways to do that shown below in psuedo-python. This first way has no trouble with 3.x versions.
if kernel_version.startswith('2.4.'):
DO_A
else:
DO_B
On the other hand, if you check for 2.6 instead of checking for 2.4... Well when it encounters 3.0 the code falls back to 2.4 behavior.
if kernel_version.startswith('2.6.'):
DO_B
else:
DO_A
Sadly a number of binary only RAID tools don't really get updated much and have these problems. There is a program in util-linux named uname26 that you can run these tools under which gives them the 2.6.40+ version numbers.
This is just one of those tricks operating systems have to resort to from time to time, its like how Microsoft is skipping Windows 9 because of how many programs execute version.startswith('Windows 9') and assuming that means Win95/Win98.
Basically, some programs had issues working with Linux 3.x version numbers, so the kernel can lie to these and say that its version isn't, say, 3.0, but actually 2.6.40. This was implemented by just taking the kernel minor version number and adding 40 to it and tacking that on to "2.6."
So, the problem here is that version 4.0 has that same code, so it's also going to fake-report its version as 2.6.40 when using the UNAME26 personality.
A surprisingly large amount of code still works. If your code is statically linked the syscalls have not changed, due to Linux's backwards compatibility guarantees, and if it was dynamically linked against glibc the glibc compat may work, or you can just use the old glibc and linker.
How much useful code there is that cant be recompiled I dont know, but I am sure people have some, and they probably dont want to run it in an old unsupported distro.