Bug 593560 - kernel: version number
Summary: kernel: version number
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.0
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Red Hat Kernel Manager
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-19 06:54 UTC by Jan Engelhardt
Modified: 2010-05-20 17:05 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-05-19 18:22:33 UTC
Target Upstream Version:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.