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."
What most people don't realize that someone who puts together these releases like Linus or Marcelo is by no means omniscient. The kernel is a huge piece of work, and no one person can know what's happening in every corner of the thing. Most of Marcelo's time goes to merging patches, so he surely cannot go around the net looking for what ever fixes some distributor might have used or even checking out how come some fix that was circulating around before was never submitted to him.
What's nice is that nowadays there seem to be a couple of "patch harvesters" on the lkml who create their own releases (Alan Cox is now one of these people!) and persistently keep submitting forgotten patches.
An example of why a particular patch might not be accepted, even though it seems like a "no-brainer", is because it would be for too specific a purpose. It might optimize the kernel for one particular application, at the expense of others. One of the best things about Linux is that it is general-purpose: suitable for everything from palmtops and embedded systems to servers and enterprise applications.
A patch to aggressively cache the disk in memory, for instance, might be good for servers but not for embedded systems. So, I could understand how a patch would be rejected in this case.
As an example, a company I once worked for made many minor changes to the Linux kernel. Since Linux is GPL, I made a webpage publishing these changes, and unlike the company, my webpage is still in existence!
Splash Open Source Page
These changes would be too narrow in focus to apply to the Linux kernel for everybody, so we never submitted them.
Dr. Demento On The 'Net!
Out of all the people involved with this on the planet, not one person could be assigned the task of doing this sort of sweeping up? Lots of busy folk out there, certainly, but those people were found to do the major stuff in the first place... And please, save the "well why don't you do it, smarty man?" responses for someone that sort of backwards logic will work on, thanks, I'm just making an observation, not an accusation.
BytesTemplar.com
Careful.
:wq
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.
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
Then why are you posting on /.?