New column: Ask a kernel developer
Hi, and welcome to a new semi-weekly column. In here, we are going to try to answer your common questions about Linux kernel development. This column will rely on the readers to submit new questions to be answered either here in comments, or by email to greg@kroah.com, with the understanding that not all questions can be answered.
Valid topics can range from the technical, to the procedural, or on toward anything remotely related to the Linux kernel that you can think of.
To start it off, I've provided a few "seed" questions that I get asked a lot, and would like to finally answer in one place so I don't have to do it again.
Why is the 2.6.27 kernel still being maintained while the newer 2.6.29 kernel is no longer getting updates?
The Linux kernel stable series strives to only maintain one kernel tree at at time, the most recent one, with a small overlap of a release or two when a new kernel is released. So for right now, as the 2.6.31 kernel was just released, both the .31 and .30 trees are being updated. After the next release of the .30 stable tree, it will be abandoned, and only the .31 tree will be updated with security and bug fixes.
But some kernel trees are a bit "special". The 2.6.27 kernel looked like a good kernel to maintain for a longer period of time. Some users have reported that they like to remain on one kernel version for longer than 3-4 months, so the 2.6.27 kernel tree will try to be a tree that they can rely on to get security and bug fixes for a longer time frame. As the 2.6.27 kernel was first released on October 9, 2008, there has almost been a full year of support for this kernel so far.
After I get tired of maintaining this kernel branch, Adrian Bunk has volunteered to maintain it even longer, so in another year or so, maintenance will switch over to him, and it will continue to live on.
How do I get a patch included in the stable kernel updates?
First off, take a look at the file Documentation/stable_kernel_rules.txt to verify that the patch you are considering meets the rules for a stable kernel release. If it does, the easiest way to get it included is to add a:
Cc: stable <stable@kernel.org>
line to the Signed-off-by: area in the patch before it is sent to the subsystem maintainer. When a patch with that line in it is accepted into Linus's kernel tree, the stable team will be automatically notified that the patch should be included, and they will queue it up for the next stable kernel release(s).
If you notice a patch that you feel should be included in the stable release, and does not have this marking, and is already in Linus's tree, a simple email to the stable@kernel.org address with the git commit id of the patch in Linus's tree and a short description of which stable kernel releases you feel it should be included in is all that is needed.
So bring on the questions!
| Index entries for this article | |
|---|---|
| GuestArticles | Kroah-Hartman, Greg |
