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: 1. 2. 3. Actual results: Expected results: Additional info:
eh and just reading the specfile which has all 40 or so patches documented doesn't cut it ?
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 :-)
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...
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.
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.