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