Differences

This shows you the differences between two versions of the page.

--- civilinfrastructureplatform:cipkernelmaintenance [2017/11/17 19:48]
anniefisher
+++ civilinfrastructureplatform:cipkernelmaintenance [2023/09/28 06:49] (current)
jki-siemens avoid confusion about up to 20 years maintenance
@@ Line 1: / Line 1: @@
 ====== Kernel Maintenance ======
-October 23, 2017 – The Civil Infrastructure Platform (CIP), which aims to provide a base layer of industrial grade open source software components, tools and methods to enable long-term management of critical systems, today announced the release of the CIP Core. The CIP Core, a reference minimal file system that offers a customizable environment that developers can use to test the CIP kernel and core packages, was on display at Embedded Linux Conference Europe with planned workshops, demos and Q&A sessions.
+This wiki page describes the policies and recommendations that the CIP kernel maintainers are following in order to maintain the CIP kernel beyond the current periods established by the enterprise industry, in order to meet Industrial Grade requirements.
-CIP aims to speed implementation of Linux-based civil infrastructure systems, build upon existing open source foundations and expertise, establish de facto standards by providing a base layer reference implementation, and contribute to and influence upstream projects regarding industrial needs.
+===== Kernel maintenance team =====
-Hosted by The Linux Foundation, CIP addresses the needs of long-term software for the power generation and distribution, water, oil and gas, transportation and building automation industries. CIP members such as Codethink, Hitachi, Plat’Home, Renesas, Siemens and Toshiba are working to create a reliable and secure Linux-based embedded software platform that can be sustained more than 10 years and up to 60 years.
-“CIP is committed to creating, testing and maintaining an open source software foundation needed to deliver essential services for civil infrastructure and economic development on a global scale,” said Yoshitake Kobayashi, Chair of CIP’s Technical Steering Committee and the Senior Manager of Open Source Technology Department at Toshiba. “The CIP Core is a major milestone that will provide a platform for developers to easily build a reference file system and quickly test the CIP kernel with specific application and use cases. This customizable testing will eventually became a part of the product solution.”
+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 Core features include:
-- Creating reference file system images to test and demonstrate use of the CIP kernel and core packages, a selected set of open source software components that require super long-term support.
-- Achieving its first milestone after releasing reference file system images for the Beaglebone Black, the iWave RZ/G1M Qseven Development Kit, QEMU x86_64 and the DE0-Nano-SoC development kit.
-- Consolidating the CIP kernel and core packages into a minimal reference file system that can be tested and used for further development.
-- Leveraging released file system images that were generated with Deby, a reproducible and maintainable embedded Linux distribution currently based on poky and Debian LTS source code.
-Board at Desk v1.0:
+===== CIP kernel maintenance policies =====
-CIP also recently launched Board AT Desk (B@D) v1.0, a customized and easy to deploy instance of the kernelci and LAVA projects that should allow developers to test Linux kernels on boards connected to their own development machines using the tooling provided by one of the most successful Open Source testing projects, kernelci.org. B@D v1.0 is provided as a vagrant virtual machine (VM) image/recipe and as a VM image, known as a Vagrant box.
-With this release, CIP is moving towards a “shared and trusted testing” target for not just those directly involved in maintaining the CIP kernel but any kernel developer that has physical access to a board. It reduces the deployment, configuration and maintenance costs. B@D introduces a “local” approach to kernelci.org which is a distributed service centrally managed. In addition, CIP intends to increase the number of developers and organizations willing to participate in kernelci.org by providing a simple mechanism to evaluate the technologies developed by that community (LAVA and kernelci) which CIP considers upstream. For more information about the B@D v1.0, read this blog post [[https://www.cip-project.org/blog/2017/10/18/cip-launches-bd-v1-0]].
-===== Maintenance policies =====
 ==== 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, so that typically only 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.
 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 will maintain it for two years (Feb 2018) following the kernel LTS process. 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.
-November 17, 2018 Update:  Linux version 4.4.98-cip13 was released by Ben Hutchinson.  This removes the in-tree firmware, adds support for some new hardware watchdog features, and includes all the fixes from stable versions 4.4.93-4.4.98 inclusive.
+The Linux kernel 4.19 was released on October 22nd, 2018.
 ==== Suitable changes ====
@@ Line 62: / Line 54: @@
   * Architecture and hardware support will be limited to the needs of CIP members; fixes for other hardware will not be applied except where that makes it easier to apply the fixes we do need.  For the 4.4 branch, the architectures we've committed to so far are arm (32-bit) and x86_64.
-  * Some features, particularly those labelled as experimental, may also be excluded from support.  We have not done so yet.
+  * Some features, particularly those labelled as experimental, may also be excluded from support. We have not done so yet.
-Unlike an LTS branch, an SLTS branch may include larger changes to
+Unlike an LTS branch, an SLTS branch may include larger changes to support new hardware, to bridge the gap between SLTS branches. However, this should only be done on the newest SLTS branch.
-support new hardware, to bridge the gap between SLTS branches.
-However, this should only be done on the newest SLTS branch.
 ==== Releases ====
@@ Line 76: / 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.
-===== Support =====
+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.
-==== Scope ====
+==== Maintenance Scope ====
-CIP maintainers will support and respond to bug reports from CIP members and their developers, but not system administrators or end users.
+CIP maintainers will maintain and respond to bug reports from CIP members and their developers, but not system administrators or end users in general, about upstream patches. Bugs should be reported upstream.
+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. 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]]
-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.
 ==== Security fixes ====
@@ Line 90: / 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!
-We plan to track [[https://cve.mitre.org/about/|CVE]] status in each branch and provide this information either to members or publicly.
+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 =====
+These recommendations has been written by Ben hutchings.
+==== Find the patches ====
+If you are doing this after a stable release, all the patches will be in the git history of the branch.
+If you want to do this during the review period before release, you should be able to receive the patches through the [[http://vger.kernel.org/vger-lists.html#stable|stable@vger.kernel.org]] list. This is a high-traffic list, so you may want to filter by subject.  However, at the time of writing, Greg's script that sends patches out for review has a bug that causes patches with non-ASCII characters to be dropped.  Greg and most other stable maintainers also publish pending patches in a git repository, either as a quilt patch
+series or as a rebased git branch.
+Pending patches for stable can be found at:
+   * 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 (Sasha) Levin [[https://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git/|queue]].
+==== 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.)
+==== Read the commit message ====
+Does the commit message explain why the change is important, i.e. does the explanation seem to fit the criteria for stable?  If not, maybe this doesn't belong in the stable branch. But do consider:
+   * Sometimes an unimportant commit will be included because it's a dependency of an important fix.  Look at the following patches to   see if they're related.
+   * Sometimes a commit that didn't seem important at the time turns out to be important later, e.g. cleaning up a function turned out to fix a corner case that was a security flaw.  You can check the stable mailing list archives to see if someone requested it and why.
+   * If the author is Linus, be aware that he often makes security fixes without describing the security implications.
+Look for a ''Fixes:'' tag in the commit message, identifying which commit introduced (or only partly fixed) the bug that's being fixed:
+   * If it's not present, look to see if the free-form text identifies which commit introduced it.
+   * Is that commit actually present in the stable branch? Don't forget that it might have been backported as part of another stable update.  If not, this probably doesn't belong in the stable branch.
+   * Find the first release containing a commit:
+> ''%%git describe --contains --match 'v*' %%**//hash//**''
+   * Check whether a stable branch contains a backported commit:
+> ''%%git log --pretty=oneline --grep=%%**//hash//**%% v%%**//version//**..stable/linux-**//version//**.y''
+The ''git-check-in-stable'' script from [[https://anonscm.debian.org/cgit/kernel/kernel-team.git/|Debian kernel/kernel-team.git]] provides a shortcut (and slightly nicer output format) for the second command.
+==== Read the code ====
+Patches only have 3 lines of context around the lines being changed, but in some cases you need to consider the whole of each function (or other definition) being changed. So you will often need to look at the files being patched, not just the patches.
+   * Does the patched code appear to do what the description says?
+   * Does the description cover all the code changes, or are there other changes which might not be appropriate for stable?
+      * 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 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.
+   * 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?
+==== When you find a problem ====
+If you find a regression that is specific to the stable branch, it should be fixed by revising or rejecting the patch for the stable branch, or (if it has already been applied and released) by adding another stable-specific fix.
+If you find a regression that's also present upstream, it should be fixed upstream first.  In fact, that might already have happened:
+   * 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).
+==== 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]]

Wiki

User Tools

Site Tools

Differences

Page Tools