Description of problem:
The RedHat kernel has a version, that is, the "LINUX_VERSION_CODE" macro does.
RedHat itself however announced on http://press.redhat.com/2010/05/05/red-hat-enterprise-linux-6-kernel-an-overview-and-genealogy/ that "the Red Hat Enterprise Linux 6 kernel cannot be simply labeled as any particular upstream version."
Version-Release number of selected component (if applicable):
RHEL6 beta with "kernel-devel-2.6.32"
Install said package.
LINUX_VERSION_CODE is defined to represent one particular upstream version, KERNEL_VERSION(2,6,32).
LINUX_VERSION_CODE should not represent any particular upstream version. Looking into the kernel history, upstream owns all values >= 65875 (1.1.83).
Suggestion to do #define LINUX_VERSION_CODE 0
Jan, describing the kernel as no version at all will break compilation of all kinds of stuff, mostly device drivers that our users build for specialized and/or strange hardware.
The subsystems in the RHEL 6 kernel are close to their upstream counterparts from 2.6.32 through 2.6.34. Some subsystems (eg. DRI/DRM, KVM, the VM, etc.) are closer to 2.6.34, while others are closer to 2.6.32.
During the lifetime of RHEL 6, some subsystems and drivers will probably end up being updated to match what is in even newer upstream kernels, which do not exist yet at this point.
That leaves 2.6.32 as the lowest version number that makes sense. It is not 100% accurate since so much code is newer than 2.6.32, but it's better than nothing :)
>Jan, describing the kernel as no version at all
Well, you can use the value "1" if 0 conveys the meaning of 'nothing' to you :-)
As the amount of backport goo increases, keeping LINUX_VERSION_CODE at 2.6.32 however is not right. RHEL 5 suffers from the problem that someone decided to backport skb accessor functions, which needlessy drove module tarballs doing
#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,21)
# define ip_hdr(skb) ((skb)->nh.iph)
into double definition errors other compile errors.
I'd certainly want a way that I can test whether a kernel is original or has had its API changed, and preferably so without invoking or testing for any distro-specific files, file contents (currently I'm grepping /etc/redhat-release and throw a pre-warning whenever there's RHEL5 in it) or else.
Many subsystems, including KVM and (I believe) DRM, have subsystem specific code for finding out about code changes, no longer relying on the main kernel version.
It may be a good idea to expand that to other subsystems upstream.
But do they have a _compile-time_ mechanism to detect these changes? If so, how does it reliably work? What if exactly that subsystem version number is not backported?
A lot of it is just flags defined in .h files.
The presence of a macro or flag does not really say anything about the API of a function, though.
Hey, if you add a 'bool REDHAT_KERNEL' (SUSE does that for theirs already) and set it to =y in the redhat .config. That'd be good enough for me, because I can then &&-combine it with LINUX_VERSION_CODE to something meaningful.