Project:Kernel
Kernel Project | |
---|---|
Description | The Kernel Project aims to deliver the best possible experience from its sources across all supported architectures. |
Project email | kernel@gentoo.org |
Mailing list | gentoo-kernel@lists.gentoo.org (archive) |
IRC channel | #gentoo-kernel (webchat) |
Lead(s) |
Last elected: 2021-04-14 |
Member(s) |
|
Subproject(s) (and inherited member(s)) |
|
Parent Project | Gentoo |
Project listing |
With an ever-increasing user-base demanding a higher quality of stable, production-ready kernel sources and featureful desktop support the professionalism and staffing of the kernel project are very important. Because we as users want the best from Gentoo Linux we supply a selection of both generic and specialized sources capable of handling the day-to-day grind to make life a little easier.
In order to provide a rich choice of high-quality kernel trees, Gentoo Linux must apply, write and test several kernel patches to the official upstream releases before they can offer finished ebuilds to the users. This is where the Gentoo Kernel project comes into play. By maintaining quality control, clearly defined roadmaps, highly skilled developers and a standard base across all of our kernels the project will help bring the end-user experience of our kernels to even higher levels.
Kernel project meetings logs
Information on vulnerabilities
Subprojects
The kernel project has the following subprojects:
- sys-kernel/gentoo-sources
- Full sources including the Gentoo patchset for the upstream branches.
- Lead: Mike Pagano (Mpagano) , Arisu Tachibana (Alicef)
- sys-kernel/mips-sources
- Gentoo Kernel based from the 4.14.y, 4.19.y, and 5.4.y kernel.org LTS branches supporting MIPS processors.
- Lead: The MIPS project, see the MIPS project for a list of members.
- Automatically check new kernel
- Automatically configure the kernel settings
- Automatically install the kernel
- Automatically clean old not used kernel
- Automatically build and install live patch
Other kernels
The Gentoo Kernel project maintains the following list of kernels currently in portage. Additional kernels in portage that are not listed below are not maintained under the kernel project.
- sys-kernel/rt-sources: Adding PREEMPT_RT for real-time capabilities.
- sys-kernel/git-sources: Git sources, the absolute latest kernel available.
- sys-kernel/vanilla-sources: Full prepatched/rc LTS branch sources for the Linux kernel.
- sys-kernel/pf-sources: Linux kernel fork including genpatches and multiple experimental features, such as UKSM.
Genpatches
Many kernels in Gentoo include part or all of the genpatches patchset. genpatches is focused on being a minimal patchset mostly focused on bugfixes, with minimal deviation from the upstream Linux kernel.
The genpatches homepage can be found at https://dev.gentoo.org/~mpagano/genpatches.
Genpatches Supported Kernel Versions
As part of a an effort to streamline developer capacity, the maintainers of gentoo-sources and genpatches have decided to limit past kernel versions to a maximum of 2 years post initial release to match upstream kernel LTS support.
Notes:
- This impacts all kernels that utilize the official genpatches releases as part of their kernel packages including but not limited to the list here [1]
- sys-kernel/vanilla-sources will continue to follow the upstream release and deprecation schedule. Note that the upstream release schedule is showing their LTS kernel support timeframes going from six years to two [2]
- gentoo-kernel will also be following this 2 year kernel support and release policy
Why should I not run older kernel versions?
- Upstream maintainer Greg Kroah-Hartman specifically recommends the following list of preferred kernel versions to choose from in order: [3]
- Supported kernel from your favorite Linux distribution
- Latest stable release
- Latest LTS release
- Older LTS release that is still being maintained
Greg specifically called out Gentoo's method of consistently rolling out kernels with both security/bug fixes early and keeping up with upstream's releases.
Gentoo still does and will continue to offer a variety of kernels to choose from with this change.
[1] https://dev.gentoo.org/~mpagano/genpatches/kernels.html
[2] https://kernel.org/category/releases.html
[3] http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/
Maintainers guide
In order to encourage new contributors, we have documented the procedures used when maintaining gentoo-sources.
The document can be found here.
Documentation
- Gentoo Linux kernel guide
- Gentoo Linux kernel upgrade guide
- Gentoo Linux kernel configuration guide
- Gentoo Linux 4.7 releasing explanation
- Gentoo Experimental patchset
- Gentoo Linux 2.4 to 2.6 kernel migration guide (deprecated)
Kernel stabilization
The following policy is in place for kernel stabilization that can be performed by members of the kernel team without opening a stabilization bug. For this to occur, the following procedures must be followed:
For new kernel major point releases (e.g. 4.12.0)
- A stable request bug is opened and arch teams stabilize as per existing policy. No auto stabilizing occurs here as only the arch teams can really determine if the kernel is working on their own arch.
For subsequent security related releases of a kernel point release (eg. 4.12.1. 4.12.2)
- If the kernel team determines a significant security fix is included for a kernel release of 4.x.y where 4.x.(y-1) has already been stabilized per the first bullet, the kernel team can auto stabilize that specific version.
- Dependent upon the severity of the security bug, (root exploit, minor module) the kernel team will remove stable keywords from earlier versions of the same 4.x.y series within a reasonable time frame.
Mailing lists
gentoo-kernel@lists.gentoo.org
The Gentoo Kernel Mailing List is a public mailing list for the discussion of project related topics and release announcements for genpatches, vesafb-tng, and fbsplash.
Gentoo maintains a a full listing of all public Gentoo mailing lists as well as information on how to subscribe and unsubscribe.
External resources
- Doing a Kernel_git-bisect to find a bad kernel commit that causes your problem; for an alternative version, see this article.