Bug 593560

Summary: kernel: version number
Product: Red Hat Enterprise Linux 6 Reporter: Jan Engelhardt <jengelh>
Component: kernelAssignee: Red Hat Kernel Manager <kernel-mgr>
Status: CLOSED NOTABUG QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: low Docs Contact:
Priority: low    
Version: 6.0CC: riel
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-05-19 18:22:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Jan Engelhardt 2010-05-19 06:54:14 UTC
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"

How reproducible:
Install said package.

Actual results:
LINUX_VERSION_CODE is defined to represent one particular upstream version, KERNEL_VERSION(2,6,32).

Expected results:
LINUX_VERSION_CODE should not represent any particular upstream version. Looking into the kernel history, upstream owns all values >= 65875 (1.1.83).

Additional info:
Suggestion to do #define LINUX_VERSION_CODE 0

Comment 5 Rik van Riel 2010-05-19 18:22:33 UTC
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 :)

Comment 6 Jan Engelhardt 2010-05-19 19:00:35 UTC
>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)
...
#endif

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.

Comment 7 Rik van Riel 2010-05-19 19:41:34 UTC
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.

Comment 8 Jan Engelhardt 2010-05-19 19:58:14 UTC
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?

Comment 9 Rik van Riel 2010-05-19 22:24:36 UTC
A lot of it is just flags defined in .h files.

Comment 10 Jan Engelhardt 2010-05-20 17:05:54 UTC
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.