Bug 129630 - Locatable Listing of Kernel Patches
Summary: Locatable Listing of Kernel Patches
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 2
Hardware: All Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-08-11 03:26 UTC by Sam Williams
Modified: 2015-01-04 22:08 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-26 04:21:27 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Sam Williams 2004-08-11 03:26:55 UTC
Description of problem:
I work in a group of embedded developers. We occasionally see a new
Redhat or Fedora kernel that has an attribute we want to try, but we
don't necessarily want everything in  the new kernel. There should be
a readily searchable changelog that refers to the patches which go
into the various sub-released kernels. There are lots of embedded
developers that are having fits with trying to dig this information
up, when it is already available to kernel builders...

Version-Release number of selected component (if applicable):
All versions of the kernel

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Arjan van de Ven 2004-08-11 07:09:56 UTC
eh and just reading the specfile which has all 40 or so patches
documented doesn't cut it ?

Comment 2 Sam Williams 2004-08-11 13:40:07 UTC
It could, but I contend that everyone such as I didn't know where that
was located until late last night. I literally search for hours for
this information before finding it after a rather lengthy dicsussion
on #fedora.

I would hope that the information could either have a webpage or that
the documentation could be dropped into a documentation area. For
example, the performance of the FC2 2.6.5-X and 2.6.6-X kernels from
Fedora basic sucked on my Athlon 1800xp+ based machine. I then
downloaded and built my own kernel removing all but the most essential
of features. The performance was better, but still not like I saw it
under FC1. After significantly tweaking the kernel through the /proc
filesystem I finally had 2.6.7 almost to the point where it was before.

This last weekend I downloaded, using yum, the 2.6.7-1.494.2.2 kernel
tree. It installed the kernel, System.map and initrd files just fine.
I rebooted and all of a sudden the performance was very near where I
thought it should be. I should have been able to go a website or even
the kernel source tree and see what patches were contained in
2.6.7-1.494.2.2. I already know the configs for the kernel, why would
be such a stretch to show the patch delta in a file as well?

My point is that there are many people out there that do not know that
this information is included in the SPEC file. Because of the Configs
directory many people just assume that if it isn't listed or included
it is not available.

I work in a group of aircraft power systens simulation engineers. We
use Linux extensively, yet when we build kernels we don't download the
source from Redhat/Fedora. We go to kernel.org. Sometimes there is a
single new function or feature that we need to work with, therefore
only need a single patch. It is difficult to find this information.

One of my colleagues is working on a Linux machine to control a
multi-million dollar test facility. He had a question regarding when
the  NPTL capability became available. I told him that I thought it
came in Redhat 9, but wasn't completely sure. He looked for days
before he was able to realize when and where it came from.

My point is there are many high level developers that are
understaffed, and over burdened and trying to help the Linux migration
into corporate infrastructures. Easily providing this information
would be a service that would assist many developers that are
currently getting rather frustrated. 

BTW, this is also one of the reasons why many technical programmers
avoid the Redhat / Fedora kernels. Primarily because they don't know
whats in them. 

Anyway, thanks for responding to the post. Please give it some
thought. Thanks for all your help in the kernel community too :-)

Comment 3 Rik van Riel 2004-08-11 13:52:53 UTC
Note that most of the changes in the Fedora kernel do not come from
the patches that Red Hat adds, but from the new version of the
upstream kernel that the Fedora kernel RPM switches to.

In fact, the majority of Red Hat's 2.6 kernel development is happening
in the kernel.org source tree, not in the Fedora RPM...

Comment 4 Sam Williams 2004-08-12 02:04:05 UTC
I realize this, but when either redhat or fedora release a sub-release
it is among other things based on patches that were not included
within the kernel.org tree. My request is to somehow get an easy to
locate and view listing of what makes a sub-release a sub-release. For
instance in the newest Fedora kernel, I've notices that there is
something called "voluntary preemption" this is not in the main stream
kernel source.

My request is to try to help ISV's such as the team I work with
identify where these changes are or where they originated. I'm
perplexed why including a list would be difficult because after all
the Configs directory is included and that is not part of the
kernel.org tree either. Since my primary job is developing or help
developing linux based solutions I wanted to minimize the time that I
or my other team members need to spend seeking this information.

Comment 5 Dave Jones 2004-10-26 04:21:27 UTC
maintaining such a list is a full time job in itself. Tracking the amount of
change that goes into an upstream point release is a lot of work.
Typically the Fedora changes that are added between releases are kept to a
minimum, and where appropriate documented in the release notes of each errata
kernel.  Additionally, the %changelog section in the specfile should contain any
relevant information.

Soon, our internal CVS will be made public, so 'tracking' our change can be done
on a day-by-day basis.

Other than that, things probably aren't going to change a lot.

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