RHEL Kernel Versions

[Jarod Wilson]

On Tue, 2008-05-13 at 20:33 -0400, Kenny Lussier wrote:
> 
> 
> On Tue, May 13, 2008 at 5:55 PM, Bill McGonigle
> <bill at bfccomputing.com> wrote:
>         On May 13, 2008, at 17:42, Kenny Lussier wrote:
>         
>                  Is there any way to tell what the
>                 kernel patch level is and what the patches are in the
>                 RH kernels?

Nb: for Fedora, we now have rpm versioning that matches up exactly with
what the upstream kernel base is. For example, my laptop is presently
running 2.6.25.3-8.fc9, and a 2.6.25-rc3-git2-based kernel rpm version
was something like 2.6.25-0.<rpm release #>.rc3.git2.fc9. 

>         If the changelog isn't enough, get the SRPM (yumdownloader
>         --source works sometimes) and look at the SPECS/kernel.spec
>         file for a full list of patches.
>         
>         Yes, the kernel is that old, RHEL is for 5-year stability, not
>         tracking current work (with the occasional backported
>         exceptions).  Fedora gets you the current stuff, but you're
>         bound to be upgrading every year.
>         
>         -Bill
> 
> 
> I think that this is why I've always used kernel.org kernels in the
> past.

Then you quite likely shouldn't be using RHEL, to be honest. A *TON* of
effort goes into the kernel, which never gets rebased from the original
kernel version shipped for that release. RHEL4 shipped with a
2.6.9-based kernel, and will always have a 2.6.9-based kernel. RHEL5 is
a 2.6.18-based kernel, and will always be a 2.6.18-based kernel. And so
on.

> When someone comes to me and says "I need kernel x.y.z because it has
> <insert feature or performance enhancement here>", I can get that
> kernel for them.

These random people who come up to you and say "I must have this
kernel"... Do they really truly know what they're talking about? Many
snazy new features and loads of hardware enablement and performance
enhancements typically get backported to the RHEL kernels. Actually, a
fairly good percentage of the time, they get implemented FIRST on RHEL
kernels because of Red Hat customer demand, and then get submitted for
upstream inclusion as well.

> With RHEL, you eliminate support when you put in a kernel that isn't
> one of theirs.

Yep.

Hm... I should do a GNHLUG talk on the Red Hat and Fedora kernel
development process, it seemed to go over pretty well at LinuxFest
NorthWest last month...


-- 
Jarod Wilson
jarod at wilsonet.com