Slashdot Mirror
Missing Kernel Patches
BlueEar writes: "There is an interesting, short story posted on the Gentoo Linux site. It talks about kernel patches created by Linux distributors that while publically available never get submitted. It even gives an example of one 'no brainer' patch that has been sitting over a year, without being incorporated into the 2.4.x distribution. The article ends with an appeal to Linux community to keep those patches flowing to Marcelo."
> why doesn't someone start a Linux code review project ???
Then, what is http://kerneljanitors.org, mentionned at the end of the article?
Many of the distributor's fixes are ad hoc kludges that are designed to quickly making the thing *work*, ignoring elegance and maintainability...
I don't understand why a distro would bother shipping a kernel (or app for that matter) with a patch that was "ad hoc". It wouldn't exactly endear their customers to provide repeat business.
I think you will find that most distros test their patched kernels thoroughly before releasing them to the world. This would include not only checking that the patch fixes the problem, but that it compiles on all supported architectures and does not jeopradise future modifications to the same bit of code or adjacent or related pieces of code.
Why they don't submit all the patches to the kernel maintainer I don't know? Maybe the patch was submitted and was passed over or missed and then not resubmitted.
marty
"I can't buy want I want because it's free. Can't be what they want because I'm me." -Corduroy, Pearl Jam
Careful.
:wq
could be that whoever produced the patch (Mandrake in this case) got tired of having to submit it over and over, only to have it ignored bye (for example) Linus. i'm not complaining here, but i think at least part of the solution to this "problem" relates to how the patches are handled by the maintainers.
Acts@core.mailboks.com Acrux@core.mailboks.com Adam@core.mailboks.com Adar@core.mailboks.com Ada@core.mailboks.com
I remember when Redhat attempted to modularise the sound drivers for one of the 4.x releases. They ended up with Soundblaster drivers working as modules, but every other card driver was completly broken.
Precisely. This patch was in fact submitted and the consensus was thats its tricky to prove correct, its 1 page of memory and it was better to wait for 2.5 before doing that work.
Marcelo is certainly well aware of the existance of many patches that never get included in the main kernel tree, as he maintains Conectiva's kernel package which contains a large amount of vendor patches. He certainly has his reasons for not including the patches to the official kernel -- it certainly would make his life much easier if he reduced the number of vendor patches in Conectiva's tree applying some of these to the main tree. Marcelo is being very conservative regarding the 2.4 tree, and I believe that's the way it should be, considering it's a "stable" kernel.
I am wondering if the distributors themselves don't have too much interest in offering patches upstream
This plain isn't true, and whoever wrote the article on gentoo.org just shows he doesn't have the slightest hint of a clue.
There are some good reasons not to blindly apply distributor patches into the main kernel (for example, we have quite a few workarounds for bugs, but the right way to fix them in the official kernel is to fix them, not to add workarounds), and there are some other things preventing other patches from getting in (e.g. Linus not having the time to handle them immediately).
Other stuff is controversial (such as Red Hat Rawhide kernels putting in the Rik VM rather than the AA VM currently in upstream).
The patches are sent upstream, but at least Red Hat doesn't believe in forcing upstream maintainers to accept all patches we send.
This message is provided under the terms outlined at http://www.bero.org/terms.html
I don't understand why a distro would bother shipping a kernel (or app for that matter) with a patch that was "ad hoc"
Easy: Because a kludgy workaround is preferrable over a bug, and we don't always have the time to fix things the right way.
I think you will find that most distros test their patched kernels thoroughly before releasing them to the world. This would include not only checking that the patch fixes the problem, but that it compiles on all supported architectures and does not jeopradise future modifications to the same bit of code or adjacent or related pieces of code.
This is true - but it doesn't include checking for stuff that's just a workaround for a bug with a relatively bad code quality.
Why they don't submit all the patches to the kernel maintainer I don't know?
Because the guy who wrote the article either didn't check the facts or lied.
At least as far as Red Hat is concerned, patches do get submitted.
This message is provided under the terms outlined at http://www.bero.org/terms.html
I'll agree with the versioning/branching comment, although I'd say that ClearCASE, cvs, pretty much anything would be more stable than VSS. Also, VSS doesn't make it nearly as easy to branch as ClearCASE - in VSS you seem to have to branch the whole project, in ClearCASE you can branch individual files and directories, so you never have to merge more than you need to.
Unfortunately, the Linux kernel configuration management paradigm seems to be more of developers maintaining separate trees, and then handing off patches between trees instead of patches that move between branches. I think this is because for a branching scheme like ClearCASE, you need a centralized authoritative repository to say who has branched from where, and when. Linux has no central branch directory like that, and the patch format commonly used doesn't encode this sort of information. So you can't do automatic conflict resolution (or at least you can't do as much as you'd like) without a branch directory under central control.
Branches make sense to me - I use them every day. But Linux, at the moment, isn't set up to use them very well. And in moving to bitkeeper they're going even farther down the path of handling trees rather than branches.
Your right to not believe: Americans United for Separation of Church and
It seems like it would be trivial for vendors to maintain their patches in their own BitKeeper repository. If done consistently across vendors, it would allow the kernel maintainers to merge patches into the standard distribution with minimal effort.
Moreover, this would probably make it easier for anybody to track different sets of patches. Imagine being able to use an SCM tool to help minimize the pain of tracking patches through several kernel revs. Many of us do this on a daily basis anyways and would love to see such tools used properly in the open source community.
...And no, I'm not trolling.
/.).
People talk about the exchange of ideas between the BSDs and Linux, and I think that a core group like FreeBSD's would be a great idea for the Linux world.
It seems like we are running into more and more scaling issues with the people behind Linux than with Linux itself. This is no fault of theirs. Linux is too big a project for a "the buck stops here" kind of person like Linus.
Obviously, Linux is Linus's brainchild, and he can do whatever he likes with it (yes, I know the GPL allows forking, but think of how a kernel fork would be recieved on
I don't believe that Linux can attain the kind of consistency (and that is not the goal anyway) of FreeBSD or NetBSD, I think they might be able to fix some of the kernel patching and architecting problems if an elected core team could work on this.
-Peter
. Penguins Surely Ca