August 2020

The Civil Infrastructure Platform has several work groups that ensure things keep running. Below is a Q and A with the CIP Kernel Team. 

1. What is CIP Kernel Team (What does this team work on, what issues does it solve)

While the CIP project aims to establish an open source base layer (OSBL) of industrial grade software to enable the use and implementation of software building blocks for civil infrastructure, CIP Kernel Team is responsible for Linux kernel in OSBL to sustain industrial grade systems or devices during their life cycles.

2. What is the primary goal of this team?

The goal of the team is to provide CIP kernels with more than a ten year maintenance period by fixing versions to fulfill the required level of reliability, sustainability, and security.

3. What is the development principle of CIP?

CIP adopts the upstream first as our development principle. The “Upstream First” principle allows patch commits only if those patches are already in the upstream. By following this principle, if a desired patch is not in the upstream yet, this patch should be accepted by the upstream at first. Therefore, it may take time to introduce the desired patch to our project.

But, it enables us to share our outputs with the upstream.  At the same time, the risk of conflicts can be eliminated.

CIP is aiming to sustain target systems and devices during their life cycles which are very long by their nature. So the Upstream First principle is essential to achieve our goal. 

4. What is “Upstream First” for the Kernel Team?

For the CIP kernel team, upstreams are Linux mainline and LTS. The team collaborates with upstream projects. Before using their outputs, the team upstreams what the team has and doesn’t keep them locally. 

As marked 1, “Contribution” is our first action. Feature upstreaming is done by CIP member developers. On the other hand, the CIP Kernel Team contributes to upstream in a more general manner. The team developed open source tools in order to work on contributions effectively..

As marked 2, “Use” is the second action. The team uses LTS kernels to release CIP SLTS kernels. For those releases, automated testing plays a very important role. Therefore the  CIP kernel team is closely working with the CIP testing team.

As marked 3, “Integrate” is the third action. By integrating those SLTS kernels with CIP Core packages and additional packages, industrial systems or devices can be developed and maintained.

5. How does the team use LTS kernels?

The team uses LTS for CIP SLTS kernel bases. 

CIP SLTS kernels are based on LTS 4.4 and 4.19. The first releases of SLTS 4.19 and 4.19rt were done in 2019. The team plans to maintain them until 2029 for ten years. The first releases of SLTS 4.4 and 4.4rt were done in 2017, and likewise the team supports them for ten years till 2027.

Both LTS 4.4 and 4.19 are maintained for 6 years by the LTS project. So, the remaining 4 years will be maintained by the CIP Kernel Team.

6. How can CIP kernels be used?

By integrating the SLTS kernels with CIP Core packages and additional packages, industrial systems or devices can be developed. 

CIP refers to Debian for userland packages. If you would like to use Debian source packages, you can use Yocto/Poky as a build system. 

CIP core packages contain tens of packages which may not be sufficient for the development of end products. So, you can add necessary packages from Debian by writing recipes.

7. What has this team accomplished so far?

Currently SLTS 4.19 is released twice a month and 4.4 is once a month. SLTS 4.19-rt is once a month and 4.4-rt once every two months.

So far the team has steadily released CIP SLTS kernels by following release frequencies below. 

(as of June 7, 2020)

8. What are some future goals?

The team made major releases in 2017 and 2019. So, a major release frequency is once per two years so far. Another two years is going to pass, and Year 2021 is approaching. So, the team started to discuss new SLTS kernels.  

9. How can people get involved?