Hya,

Why many distros have own kernel patch?

Will these patches be included in official kernel (www.kernel.org ones) in future?

Debian (etch) kernel page reads as follows:
I know that in the past, mandrake system required its own kernel, (generic one did not work ??)

I am simply curious. Also, I do not see much reason to have "own" patch(es).

Happy Penguins!

Ultimately, it has to do with the development model that the linux kernel (and many free software projects) use. There are, in a way, two teams that work on the kernel - the kernel devs and the distro (Debian/Red Hat/etc) devs. The reason for this is that the two groups have slightly different goals.

They both want the best possible kernel. However, the kernel devs are constantly developing for the future. They make major design decisions and write most of the code. If they have to break something in the short run in order to fix something for the long run, they will. Patches are accepted to the Linux kernel (compared to distro's kernels) slowly, because they want to be very sure they get it right.

Distro devs, on the other hand, are in the business of packaging the kernel and making it work right _now_. Breakage in the short term is not good for their goals. So each distro generally maintains a set of patches that really are "patches" - temporary fixes to problems. They usually fix the symptoms of a problem, but may not always fix the cause of the problem. If the distro developers managed to fix the cause of the problem, then that patch may likely be accepted into the main kernel. If they just covered up a symptom, then the kernel devs would usually prefer to spend extra time to find the root cause.

Now, of course, it's never that simple and these two groups of developers often overlap. But the basic idea is that distro maintainers have to patch for the short run and kernel developers write for the long run.

And source-based distros don't have to be picky about kernel choice - you'll compile software with the core of your choice and your headers at your own risk, so you probably won't get segfaults later just because someone did the job for you with his kernel and dependencies, which differs from yours.

Hya,

Thanks for reply.

Happy Penguins!

Ya... to add a bit to what Patrick said...

Often times you'll find the custom patches in distributions are actually in the development kernel builds, and eventually will be in the a release kernel down the road. The kernel devs don't often, if ever, go backwards. The kernel devs may fix a bug in 2.6.30 that has been around since 2.6.11. The distribution may be running 2.6.18 and wants the bug fix but doesn't want to risk going to 2.6.30 yet. They will often backport the patch to the version they are using and release it for there distribution. RedHat has been known to go particularly far with there back porting of code, implementing entire new features from later kernels into earlier kernels to fit there needs.