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)
...
#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.

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.