civilinfrastructureplatform:cipkernelmaintenance
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
civilinfrastructureplatform:cipkernelmaintenance [2017/12/13 18:23] bwhct [Read the commit message] Improve formatting of the command lines |
civilinfrastructureplatform:cipkernelmaintenance [2023/09/28 06:49] (current) jki-siemens avoid confusion about up to 20 years maintenance |
||
|---|---|---|---|
| Line 5: | Line 5: | ||
| ===== Kernel maintenance team ===== | ===== Kernel maintenance team ===== | ||
| - | Ben Hutchings, from Codethink Ltd. is the initial CIP kernel maintainer. Daniel Wagner, from Siemens AG, joined the kernel maintenance team in 2017 as maintainer of an -rt branch of the CIP kernel. More developers will join in future. | + | |
| + | Nobuhiro Iwamatsu, from Toshiba Corporation. and Pavel Machek, from DENX Software Engineering GmbH are the current CIP kernel maintainer. More developers will join in future. | ||
| + | And when we release the CIP kernel, we will sign it with GnuPG by the maintainers. Each public key can be obtained from the following. | ||
| + | * Nobuhiro Iwamatsu ([[http://keys.gnupg.net/pks/lookup?op=get&search=0x32247FBB40AD1FA6|0x5E629EE5232197357B84CF4332247FBB40AD1FA6]]) | ||
| + | * Pavel Machek ([[http://keys.gnupg.net/pks/lookup?op=get&search=0x30E7F06A95DBFAF2|0x4F7CF3BBAF478086 4D35D2FD30E7F06A95DBFAF2]]) | ||
| ===== CIP kernel maintenance policies ===== | ===== CIP kernel maintenance policies ===== | ||
| Line 11: | Line 16: | ||
| ==== CIP kernel - SLTS kernel ==== | ==== CIP kernel - SLTS kernel ==== | ||
| - | **When does CIP define/label a kernel as SLTS (Super Long Term Support)?** | + | === When does CIP define/label a kernel as SLTS (Super Long Term Support)? === |
| New major versions of commercial Linux distributions are released at 3-4 year intervals and maintained over 10-13 years, so that typically only 3-4 versions need to be supported at one time. Given that CIP's support period is meant to be even longer, it won’t be sustainable to extend every LTS branch, but only to take on a new branch every 2-4 years. | New major versions of commercial Linux distributions are released at 3-4 year intervals and maintained over 10-13 years, so that typically only 3-4 versions need to be supported at one time. Given that CIP's support period is meant to be even longer, it won’t be sustainable to extend every LTS branch, but only to take on a new branch every 2-4 years. | ||
| Line 17: | Line 22: | ||
| The longer the intervals between new SLTS branches, the greater need there will be for CIP or individual members to backport new hardware support (which carries its own risks). This trade-off is perhaps the most difficult issue to decide. | The longer the intervals between new SLTS branches, the greater need there will be for CIP or individual members to backport new hardware support (which carries its own risks). This trade-off is perhaps the most difficult issue to decide. | ||
| - | CIP will measure the effort involved in maintaining the kernel branch we already labelled as SLTS (4.4) and study the technical implications of this work during 2017 in order to define when the next SLTS branch should be started. | + | CIP will measure the effort involved in maintaining the kernel branch we already labelled as SLTS (4.4) and study the technical implications of this work during 2018 in order to define when the next SLTS branch should be started. |
| - | **How long will 4.4 SLTS branch be maintained?** | + | === How long will SLTS branches be maintained? === |
| - | The use cases CIP project is targeting have a life cycle of between 25 and 50 years. In theory, this is the time in which products shipped with the CIP kernel will be under maintenance. However, identifying and backporting relevant fixes becomes increasingly difficult as upstream kernel development diverges further from a stable branch. Any given SLTS branch is unlikely to be maintainable for more than 10-20 years. | + | The use cases CIP project is targeting have a life cycle of between 25 and 50 years. In theory, this is the time in which products shipped with the CIP kernel will be under maintenance. However, identifying and backporting relevant fixes becomes increasingly difficult as upstream kernel development diverges further from a stable branch. Any given SLTS branch is unlikely to be economically maintainable for much more than 10 years. |
| The Linux kernel 4.4 was [[http://lkml.iu.edu/hypermail/linux/kernel/1601.1/01592.html|released on January 10th 2016]]. It was [[https://kernel.org/releases.html|declared LTS (Long Term Support) by the stable team]] which means Greg Kroah-Hartman was supposed to maintain it for two years (Feb 2018) following the kernel LTS process. In September 2017 it was announced that the 4.4 LTS branch will be maintained during 6 years. Another stable maintainer could extend LTS maintenance for some time beyond that. After that period, CIP will maintain it. | The Linux kernel 4.4 was [[http://lkml.iu.edu/hypermail/linux/kernel/1601.1/01592.html|released on January 10th 2016]]. It was [[https://kernel.org/releases.html|declared LTS (Long Term Support) by the stable team]] which means Greg Kroah-Hartman was supposed to maintain it for two years (Feb 2018) following the kernel LTS process. In September 2017 it was announced that the 4.4 LTS branch will be maintained during 6 years. Another stable maintainer could extend LTS maintenance for some time beyond that. After that period, CIP will maintain it. | ||
| + | |||
| + | The Linux kernel 4.19 was released on October 22nd, 2018. | ||
| ==== Suitable changes ==== | ==== Suitable changes ==== | ||
| Line 59: | Line 66: | ||
| As we will be backporting fixes from mainline, which [[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/stable-api-nonsense.rst|may change in-kernel APIs]], we will not guarantee API or ABI stability within an SLTS branch. It is the responsibility of members to update any out-of-tree components they use in case they are affected by such a change. However, incompatible changes to user-space APIs or ABIs will not be acceptable. | As we will be backporting fixes from mainline, which [[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/stable-api-nonsense.rst|may change in-kernel APIs]], we will not guarantee API or ABI stability within an SLTS branch. It is the responsibility of members to update any out-of-tree components they use in case they are affected by such a change. However, incompatible changes to user-space APIs or ABIs will not be acceptable. | ||
| - | Initially, CIP will release a new CIP minor kernel version approximately once a month. You can find the [[https://gitlab.com/cip-project/linux-cip|latest CIP kernel]] version in gitlab. Each release will be announced in the cip-dev mailing list and occasionally on the new section of the [[https://www.cip-project.org/news|CIP project]] website. | + | CIP has released new CIP minor kernel version. This depends on the kernel version and flavor. linux-4.4.y is scheduled to be released once a month, linux-4.19.y is scheduled to be released twice a month, and the RT kernel is scheduled to be released once every two months. |
| + | You can find the [[https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/|latest CIP kernel]] version in [[https://git.kernel.org|git.kernel.org]]. Each release will be announced in the cip-dev mailing list and occasionally on the new section of the [[https://www.cip-project.org/news|CIP project]] website. | ||
| ==== Maintenance Scope ==== | ==== Maintenance Scope ==== | ||
| Line 67: | Line 75: | ||
| The embedded systems that CIP will be used in will also often require out-of-tree drivers and will sometimes include other changes of unknown quality to their kernel. These modifications are in general unsupported. If a bug is found in such a modified kernel, Members will first demonstrate that it exists in the CIP source release in order for the CIP maintainers to act on it. | The embedded systems that CIP will be used in will also often require out-of-tree drivers and will sometimes include other changes of unknown quality to their kernel. These modifications are in general unsupported. If a bug is found in such a modified kernel, Members will first demonstrate that it exists in the CIP source release in order for the CIP maintainers to act on it. | ||
| - | For specific CIP applied patches, the default communication channel will be the [[https://lists.cip-project.org/mailman/listinfo/cip-dev|CIP-dev]] mailing list. | + | For specific CIP applied patches, the default communication channel will be the [[https://lists.cip-project.org/mailman/listinfo/cip-dev|CIP-dev]] mailing list. Patches sent to the cip-dev mailing list are tracked on [[https://patchwork.kernel.org/project/cip-dev/list/|patchwork]] since October 12th, 2018. |
| + | |||
| + | [[https://gitlab.com/cip-project/cip-kernel/cip-kernel-config|Kernel configuration files]] provided by Members will be used as a reference to limit the maintenance scope. Here is a list of recommendations related to kernel configuration for long-term support: | ||
| + | * [[https://lists.cip-project.org/pipermail/cip-dev/2017-May/000263.html]] | ||
| + | * [[https://lists.cip-project.org/pipermail/cip-dev/2017-July/000387.html]] | ||
| + | * [[https://lists.cip-project.org/pipermail/cip-dev/2018-October/001578.html]] | ||
| ==== Security fixes ==== | ==== Security fixes ==== | ||
| Line 75: | Line 89: | ||
| Although this goal may be achievable for CIP, its members may take much longer to release and deploy binary updates, maybe due to valid concerns about the risk of regression or limited opportunities to deploy updates. In the worst case, they may use CIP as an advertising/compliance point - please don't do that! | Although this goal may be achievable for CIP, its members may take much longer to release and deploy binary updates, maybe due to valid concerns about the risk of regression or limited opportunities to deploy updates. In the worst case, they may use CIP as an advertising/compliance point - please don't do that! | ||
| - | To track [[https://cve.mitre.org/about/|CVE]] status in each branch and provide this information either to members or publicly some scripts has been [[https://gitlab.com/cip-project/cip-kernel-sec|developed and published]] by Ben Hutchings. | + | To track [[https://cve.mitre.org/about/|CVE]] status in each branch and provide this information either to members or publicly some scripts has been [[https://gitlab.com/cip-project/cip-kernel/cip-kernel-sec|developed and published]] by Masami Ichikawa. |
| ===== Patch review howto ===== | ===== Patch review howto ===== | ||
| Line 89: | Line 103: | ||
| Pending patches for stable can be found at: | Pending patches for stable can be found at: | ||
| - | * Ben Hutchings [[https://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-stable-queue.git/|queue]]. | ||
| * Greg Kroah-Hartman [[https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/|queue]]. | * Greg Kroah-Hartman [[https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/|queue]]. | ||
| - | * Alexander Levin [[https://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git/|queue]]. | + | * Alexander (Sasha) Levin [[https://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git/|queue]]. |
| - | * Willy Tarreau [[https://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/linux-stable.git/|queue]]. | + | |
| ==== Filter the patches ==== | ==== Filter the patches ==== | ||
| - | Does the patch touch code that's maintained in the CIP branch? (This should be scripted. If not, ignore it and move on. | + | Does the patch touch code that's maintained in the CIP branch? (This should be scripted. If not, ignore it and move on.) |
| ==== Read the commit message ==== | ==== Read the commit message ==== | ||
| Line 125: | Line 137: | ||
| * Ignore white-space changes - they shouldn't be combined with fixes, but at least they won't do any harm). | * Ignore white-space changes - they shouldn't be combined with fixes, but at least they won't do any harm). | ||
| * If a file contains multiple similar blocks of code, is the right one being patched? | * If a file contains multiple similar blocks of code, is the right one being patched? | ||
| - | * If the patch changes a function to acquire and then release a lock or other resource, are there any additional paths through the function where the resource can leak? For example, there might be an extra //return// statement in the stable branch, compared to the upstream version. | + | * If the patch changes a function to acquire and then release a lock or other resource, are there any additional paths through the function where the resource can leak? For example, there might be an extra ''return'' statement in the stable branch, compared to the upstream version. |
| - | * If the patch adds a //return//, //goto//, or //break// statement, again check for leaks. | + | * If the patch adds a ''return'', ''goto'', or ''break'' statement, again check for leaks. |
| * Sometimes the upstream commit will have been modified (backported) to create the stable patch, because it depended on new or changed APIs, or because a function that needed to be fixed has been merged or split up in some way. If it has been backported, do the modifications make sense? If someone other than the original author backported it, they should have added an explanation in the new commit message. | * Sometimes the upstream commit will have been modified (backported) to create the stable patch, because it depended on new or changed APIs, or because a function that needed to be fixed has been merged or split up in some way. If it has been backported, do the modifications make sense? If someone other than the original author backported it, they should have added an explanation in the new commit message. | ||
| * If the patch changes the type or semantics of a function, all its callers probably need to be updated. In the stable branch, there might be additional callers compared to upstream. Have any of them been missed? | * If the patch changes the type or semantics of a function, all its callers probably need to be updated. In the stable branch, there might be additional callers compared to upstream. Have any of them been missed? | ||
| Line 137: | Line 149: | ||
| * If there is already a fix in Linus's git repository, ask for it to be included in a stable update straight away. | * If there is already a fix in Linus's git repository, ask for it to be included in a stable update straight away. | ||
| * Otherwise, if the patch that introduces the regression hasn't yet been applied then you should ask for it to be deferred (or never applied, if it was reverted upstream). | * Otherwise, if the patch that introduces the regression hasn't yet been applied then you should ask for it to be deferred (or never applied, if it was reverted upstream). | ||
| + | |||
| + | ==== CIP kernel maintenance status ==== | ||
| + | * [[linux-4.4.y| linux-4.4.y review]] | ||
| + | * new reviews are done in lts-commit-list repository | ||
| + | * [[linux-4.4-failed-patches| linux-4.4.y failed patches]] | ||
| + | |||
| + | ==== CIP kernel release tutorial ==== | ||
| + | * [[civilinfrastructureplatform:cipkernelmaintenance_release_tutorial|CIP kernel release tutorial]] | ||
| [[start|Back to the parent page]] | [[start|Back to the parent page]] | ||
civilinfrastructureplatform/cipkernelmaintenance.1513189432.txt.gz · Last modified: 2017/12/13 18:23 by bwhct
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
