On 23/04/15 16:08, Dirk Hoffmann wrote:
> 
> Is anybody reading this *and* can explain how and why SL7 chose to
> patch/fork 4.0.1 for the SL7 kernel module ixgbe?

Hi Dirk,

As Akemi have said, SL is based upon the sources provided by TUV,
stripping out trademarks and such, and then recompiled into what you
know as SL.

Now, how does such new driver appear into an older kernel release?  That
is how Red Hat works on RHEL - which is TUV.

Red Hat certifies each major release in cooperation with both software
(ISVs) and hardware vendors.  This certification ensures that any
certified software and hardware will work throughout the lifetime of
that particular major release.

Now, the computer business isn't static and doesn't want to hold off new
hardware or new feature in a release cycle OS vendors have settled on.
So for example, when new hardware arrives, and those drivers arrives in
newer kernel versions, Red Hat might backport that driver to the older
base kernel they have released.  These improvements are added in the
earlier minor point releases (6,1, 6.2, 6.3), according to the Red Hat
Enterprise Linux life cycle.  Before each RHEL release, a massive amount
of testing is done and in some cases also certifications on new
hardware.  Which means that newer hardware released after RHEL was
released can be enabled.

Now, this doesn't happen on all kind of new hardware, but is often
influenced by customer and vendor requests.  And in some cases it might
not be possible to do such backporting, due to the impact in the kernel
would be too big, such as requiring a massive change in other shared
code paths, or that data structures in the older kernel version cannot
be used in the newer driver.  The reason for backporting code instead of
rebasing is that a rebase will require a far more intrusive
re-certification.  When only changing a few parts, only those parts
needs normally to go through more vigorous testing and certification
processes.

The goal with all this is that Red Hat provides a solid OS which is as
stable as possible throughout its life cycle but also might provide
access to newer hardware the similar stability.

That is most likely what you noticed when you compared the source code
against the ELrepo kernel sources.

You also mention that you can't find the 4.0.1 release in Intel's
sourceforge project.  That might be because Intel didn't release that as
a specific release, but Red Hat did the porting from Linus's upstream
git tree where that release is found.  See this commit:

<https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9be4a9bb34746b8b87b6361462484ca42ac7089e>


(The rh7.1 is most likely just to identify which RHEL version the
backport was done against).

I hope this could enlighten you a bit more on how Enterprise Linux
works.  Using the SL kernel can often provide a far better predictable
stability than ELrepo kernels, due to have been through a far heavier QA
process.  If you have a RHEL subscription, that is also the kernel where
what Red Hat will provide support on.  Plus that subscriptions do
contribute to the pay check for all those doing this work for you.

One final note.  If you want to download the source code of packages you
have installed, you can do this:

  $ yumdownloader --source kernel

Doing an 'rpm -i' will then unpack the src.rpm into ~/rpmbuild.  And
going into ~/rpmbuild/SPECS/, you can do:

  $ rpmbuild -bp kernel.spec

Then you'll get the complete kernel code unpacked and patched, ready to
be reviewed in ~/rpmbuild/BUILD/kernel-.....  Replacing -bp with -bb
will build the RPMs.   But for building, I rather recommend using 'mock'.


--
kind regards,

David Sommerseth

-- 
kind regards,

David Sommerseth