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."

Comments

These patches can hardly be critical

[Yakman]

Based on that sample patch they gave it seems that an unpatched system allocates one more page of memory than it actually uses. Sure it's not nice in terms of resource use but it's hardly going to affect the operation of the kernel.

Obviously with the number of people (especially "power" users) who run the "generic" kernel any critical flaws are going to get uncovered and patched. I think these kind of issues, that directly affect the stability of the kernel are more important than "clean up" type patches this article describes.

Obviously they're nice to have, but it's hardly a priority when there are bigger fish to fry.

Re:These patches can hardly be critical

[jeremyp]

consensus was thats its tricky to prove correct, its 1 page of memory

So nobody can actually figure out whether this eidx thing points to the last page or just beyond the last page. I find that quite worrying...

Sounds like something from a big business to me...

[Fortyseven]

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.

Re:Sounds like something from a big business to me

[realnowhereman]

"Out of all the people who moan that these sort of issues should be fixed by someone else isn't there someone who could be ordered to do this in their own free time instead of having fun to fix this for small minded whingers like me?"

Yes, fortunately the kerneljanitors project does this. And I think they do it out for altruistic reasons rather than because someone assigned them to.

This is not backwards logic. I am not suggesting you do it. I am suggesting you stop whining about there being noone else to do it when you can't be bothered either.

Re: plz don't make fun of my head brace plz, k?

[Paelon]

Besides, you operate under the assumption that I haven't contributed anything to the kernel, which would be wrong.

I think the assumption he operates on is that you can't be bothered to go through and submit patches, as you were complaining that someone should to do it.

It's not an issue that people aren't working on the kernel enough, it's that there are too many mad scientists, and not enough henchmen.

Automate it with Visual Sourcesafe

[Otis_INF]

No, this is not a troll. Hear me out. This is an example how this work can be done using a good tool. I use Visual Sourcesafe here as an example, but any tool with the same functionality described below will do:

Visual Sourcesafe has the ability to merge back changes automatically in branch B from branch A when they have the same parent.

Say, you have the kernel v2.4.10. You branch off another project from it, call it v2.5.0. When you fix a bug in 2.4.11, you can merge it back into 2.5.0 without a hassle, it can be automated or you can do a visible merge when there are conflicts. The other way around also does work. So you can do this even further: branch of a prerelease 2.4.11-pre branch and a 2.4.11 branche from the 2.4.10 branch. Create fixes in 2.4.11-pre, merge them back into 2.4.11 after testing and when you're done, release 2.4.11 and get rid of 2.4.11-pre.

This is inside a versioncontrol system, you don't have to hassle around with a lot of files you have to merge by hand which will increase the risk for errors.

Of course, Visual Sourcesafe is just 'a' tool, you could use another which has the same functionality and is perhaps Open Source (I don't know of any but I'm sure others will). Doing this job by hand TODAY is erm... not understanding why we have computers in the first place. That's right: to serve mankind.

Agreed on the article

[clump]

I would have to agree with Bero in that the article is a tad mislead. If you listen to the mainstream Linux media as of late you would likely believe that there is a huge wealth of wonderful patches that are being dropped by Linus. This just simply isn't how kernel development works.

From Kerneltrap's wonderful interview with Andrew Morton:

there has been quite a lot of talk lately about kernel development processes, patches getting dropped, etc. I think it's all terribly overblown. The people who aren't being heard (and who aren't even bothering to comment) are the _users_ of that system - the developers. We're all just rolling our eyes and waiting for it to stop. The current system could be more efficient, but it mostly works OK; it is very unlikely to change and anything like a kernel fork is hugely improbable, even if Linus gets bored of it all and decides to do something else.

The above article should be required reading for those following/concerned about kernel development.