 Good morning, good afternoon, and good evening. Thank you very much for joining this session. This talk is about CRT Colonel Timas T.P. First of all, let me introduce ourselves. One of the presenters is Bidin-san from Moksa. He is a technical steering committee member in CRT and a governing board member of Open Chain Project. He is also actively working as deviant developer. Another presenter is myself, Masashi Kudo from Cyber Trust Japan. I had acted as Open Data Ambassador and currently act as CIP Colonel Tim Chair, CIP stands for Civil Infrastructure Platform. It was founded almost four years ago as a collaborative project under the Linux Foundation. CIP Colonel Tim was first formed in 2016. Since then, the team has actively worked and improved processes to sustain the infrastructure of civil platforms. Today, we first explain about CIP. Then, CIP Colonel Tim activity will be explained in the upstream first and CIP open source tools sessions. Testing is acting a key role of the current development. The testing activities will be explained in the CIP automated testing session. Open source tools session is covered by a data. Other sessions are covered by Kudo myself. Then, let me start with public CIP. When you hear civil infrastructure, you may imagine power plants, water gas delivery systems, disaster management systems, public transportation systems, or surveillance systems. All are true, but there are a lot more around us. Even industrial IOP devices can be categorized into civil infrastructure. The way to develop all those systems and devices has been changing. Before 2000, they had been developed with proprietary components. But after starting millennia, software layers were clearly divided into competitive layer and non-competitive layer. And people had focused on proprietary applications in the competitive layer to differentiate functionalities. Recently, the situation has become much complicated because mobile and cloud technologies have become more commodity. Systems and devices now consist of much more components, but the development resources have not been so much changed. Therefore, people are focusing only on the proprietary applications with limited resources. Now, there are millions or trillions of civil infrastructure devices which are using similar social components like Linux. They share the same industrial requirements, that is security, sustainability, and industrial gradients. They should keep satisfying those requirements during their life cycles, which are usually very long. Therefore, super long-term maintenance becomes a key. However, there were no common solutions for great building blocks of civil infrastructure. Therefore, same development and maintenance efforts should be spent each by each separately, even in same companies. By motivating to solve those issues, civil infrastructure platform, as known as CIP, sets its goal to develop building blocks to satisfy industrial requirements with open sources. We named such building blocks as open source space layer, in short OSBL. OSBL consists of CIP, SRPS kernel, and CIP core packages. SRPS stands for super long-term support, and we aim to maintain SRPS kernels for 10-plus years. CIP core packages contain only dozens of packages. They are carefully selected and will likewise be maintained for long-term. You will notice that more packages, say hundreds of packages, are needed to develop real systems or devices. While CIP provides OSBL as a commonly used building blocks, those additional packages should be added by users who are provided by Linux distributors. There are various activities listed up as candidates to achieve our goals. Among them, we selected activities, harder than numbers from one to six, in the table by gathering the member companies' opinions. Here the governance structure is explained in this slide. Governing board is organized with platinum members. It decides whom CIP should collaborate with, what CIP should invest, how budgets should be allocated, and so on. All the technical issues or directions are discussed at technical steering committee, in short TSC. All the member companies can join TSC meetings. The meetings are usually held once every two weeks on the web. Under the technical steering committee, the six activities are proceeded as teams or working groups. We formed CIP kernel team to work on SFTS kernel, as well as real-time Linux. This team was formed to work on automated testing. In addition, there are three other activities, that is CIP core team, security working group, and software update working group. Finally, there are eight member companies in CIP, and are actively working on those activities. Our annual membership fees are pooled as budget, and used to support developers or maintainers in CIP. The budget is also used to invest projects other than CIP. One of the member companies reported that up to 70% effort reduction can be achieved by applying CIP to entire organizations in the company. It is because activities like OSS license clearing, vulnerability monitoring, kernel and package maintenance, etc. can be coconut instead of doing each by each. Then let's move on to the CIP kernel team activity. The primary goal of CIP kernel team is to provide CIP SFTS kernels for 10 plus years by fixing versions to fulfill the required level of reliability, sustainability and security. There are two kernel maintenance. One kernel mentor and two kernel developers in the team. While we are highly motivated to work on the project, we don't think we can achieve the goal by ourselves only. We definitely rely on outputs from upstream projects. The question is how to use those outputs and how to work with upstream projects. Here, I show two development models. The left-hand side shows all community models. The project with this model branches its data from upstream and evolves by its own. This model enables the project to run quickly, but in the long run, it will be difficult to backport upstream patches due to conflicts. The right-hand side shows upstream-first models. The project allows patch codes only if those patches are already in the upstream. It may take time to introduce a desired patch because the target patch should be accepted by the upstream at first if it is not in the upstream yet. But it enables the project to share its outputs with the upstream. At the same time, this model eliminates the risk of conflicts. As a side note, please look at this graph. It shows the growth trend of commit counts for each LTS. As you can see, a few hundred patches are committed to each LTS per month. This trend makes cherry picking quite difficult because CIP is a long-term maintenance. The upstream-first model is a preferable approach. As explained so far, the upstream-first principle is essential to achieve industrial requirements, especially in terms of long-term maintenance. CIP adapts the upstream-first as a development principle. We collaborate with upstream projects. If we're using the outputs, we upstream what we have and don't keep them locally. By rotating, upstreaming, and using continuously, we are moving toward a goal. So what does upstream-first mean for CIP kernel team? Our upstream is line-up mainline and LTS. As much fun, contribution is our first action. Feature upstreaming is done by CIP member developers. On the other hand, CIP kernel team contributes to upstreams in more general manner. We developed open source tools in order to work on contributions efficiently. As this one will talk about those tools in detail later, as mark two, use is the second action. We use LTS kernels to release CIP S-LTS kernels. For those releases, automated testing adds a very important role. Testing assistives will be discussed later. As mark three, integrate is the third action. By integrating those LTS kernels with CIP core packages and additional packages, industrial systems or devices can be developed and maintained. I'm going to elaborate those three actions each by each. First action is contribution. Because we use upstream outputs, we value the general contributions to upstreams to be fair. Therefore, CIP kernel team works on backporting of public fixes and security touches to LTS. These statistics are the contributions by CIP kernel team to LTS. CIP S-LTS kernels are based on LTS 4.4 and 4.19, but our contributions are not limited to them. Contribution counts differ depending on the length of each line. How we contribute are recorded in commit logs in LTS. Reported by sign of by, act by, in addition to authors and PCs are major counts in the total around 1600. The second action is used. We use LTS for CIP S-LTS kernel business. As just mentioned, CIP S-LTS kernels are based on LTS 4.4 and 4.19. The first releases of S-LTS 4.4 and 4.4 RT were done in 2017. We plan to maintain them till 2027 for 10 years. The first releases of S-LTS 4.19 and 4.19 RT were done in 2019. And likewise, we support them for 10 years until 2029. CIP kernels are released by following the flow listed here. Please note that differences between CIP patches and CIP member patches. CIP patches are reviewed in G-Club, while the patches from CIP members are reviewed in Comet. CIP depth mailing list. Currently, S-LTS 4.19 is released twice a month and 4.4 is once a month. It is because Comet counts of S-LTS 4.4 are reduced. S-LTS 4.19 RT is once a month and 4.4 RT once every two months. So far, we have steadily released kernels thanks to a maintainer by following release frequencies I just explained. This chart shows how upstream releases are used in S-LTS releases. Both S-LTS 4.4 and 4.19 are maintained for six years by S-LTS project. Because CIP aims to maintain for 10 years, the rest of OEM will be maintained by CIP. We made major releases in 2017 and 2019. This means that a major release frequency is once per two years so far. Therefore, because 2021 is approaching, we started to discuss about new S-LTS kernels. The third action is integrated. Precisely speaking, this action is not done by kernel team, but by CIP kernel users. CIP refers source packages or binary packages in Debian. If you would like to use Debian source packages, you can use YoctoPoke as a build system. CIP core packages contain tens of packages, which may not be sufficient for the development of end products. So, users can add necessary packages from Debian by writing recipes. Debian provides LTS team even extended LTS. So, super long-term support, including user and packages, can be based on these teams. As I explained, CIP kernel team is effectively contributing to upstream. Open source tools were developed to help this activity. Debian will unveil how the open source tools are used in the kernel team. So, Debian, the floor is yours. Thank you, Kuro-san. Hello everyone, this is SD-Lin. It's my pleasure to meet all of you in the air. Okay, so let's talk about OpenSource tools. OpenSource tools for back-porting process. To optimize the back-porting process, improve efficiency for back-porting patches, and ease the effort from maintainers. The CIP kernel team creates and uses OpenSource tools. That is classify failed patches and CIP kernel stack in our back-porting process. The tool of classify failed patches filter and fetch the patches from the stable kernel mailing list, and classify the needs of back-porting in CIP stable kernel. The scope of the back-porting is based on CIP kernel config repository. Another tool is CIP kernel stack. CIP kernel stack tracks the status of security issues in kernel, identified by CVID. The scope of back-porting is based on CIP kernel config repository as well. As you can see, the kernel team will evaluate the results from these two projects and decided to back-port to the stable kernel or the CIP kernel, just by case. Our elaborate on the details in the next few slides. CIP kernel stack. This tool tracks the status of security issues identified by CVID in mainline, stable, and other configured branches. This repository is public, and you can link it to the project website via the QR code. The CIP kernel stack is the source code level and availability scanner. It's gathered CV information from multiple upstreams, such as stable kernel, Debian kernel, and Ubuntu kernel. The kernel team focused on maintaining the CV effected in kernel 4.4 and 4.19, and made that call the specific CV commit to the stable kernel, as the case may be. So, just like the previous slide, the CIP kernel stack provides the work queue. So, you can just use the browser to know how many CVs in your current kernel tree. And you can get the detailed information via this graphic tool. Let's talk about crossfire file patches. This project tracks the status of our patches and crossfire patches into applied and to applied types. Just like our CV kernel stack, this repository is public. So, you can also link to the website via the QR code. As you may know, the stable kernel only accepted the patches are related to bug or security fixes. Therefore, the patches in the stable archive are final to be reviewed. This project tracks the status of stable kernel patches and crossfire patches into applied and to applied types. The CV kernel team will review it and make that call the specific commit to the stable kernel, as the case may be. These are the examples to apply or to apply types. As you can see, the applied patches means these patches are already applied in the upstream. And to be applied patches means we have to spend a time to analysis and maybe adjust some conflict. And those we can send it to the upstream. Last but not the least, CV kernel convict. As I mentioned before, the CV kernel stack and crossfire patches are based on this repository to decide the action. This repository collects the kernel configuration from CV team members to define the maintenance scope in CV kernel 4.4 and 4.19 respectively. This is also the maintenance baseline for CV kernel stack and crossfire field patches. These are the updates regarding the open source tools. Thank you for your time. Kuroza, allow me to give the floor back to you. Sisa, thank you very much. Okay, then our last question is CIP test form. There are three goals defined. The first is to control the control of automated testing systems. Physical devices should be distributed in several regions by considering availability. The second is to promote continuous integration by automating testing execution on both distributed devices. The third is to support all CIP reference platforms. In this chat, I'd like to explain how the CIP testing team follows upstream cross-printing. Kernel CI and Lava are upstream of CIP testing team. The first action is to upstream code and to review code of those upstream. We are funding to Kernel CI because we agree with their goals and hope that different projects ramps up quickly in order to contribute to communities overall. The second action is use. The team uses Kernel CI and Lava to build automated testing systems. The automated testing systems are built on four testing labs located in Asia and Europe. Here is the testing architecture. 15 targets of CIP kernel sources as well as LTS release candidate. We are aiming to catch issues in LTS release candidate so that we can contribute to upstream more. The team is also working to create a container-based CI infrastructure for GitLab. Its objectives are to scale horizontally and dynamically. The infrastructure enables to run an arbitrary number of CI jobs in parallel and to scale up and down based on the current workload situation. CIP reference goals are listed here. These goals and requirements are prepared by CIP member companies and played in their own or common lab. They are set up to be connected via internet. The test trigger is applied from Lava to the goals and requirements in solving the test environment and the results displayed on the web. Finally, CIP is running two tests. Sector mail-down checker and SKP. For real-time testing, we added cyclic test plus hot bench. We plan to incorporate test-of-test in the future. These tests are executed on CIP reference goals each by each. Those test results can be checked through Lava interface. This is the list which shows scheduled testing on Lava. In order to see more detailed results, you can click bottom. CIP is collaborating with Kernel CI to improve the range of tests supported by Kernel CI, starting with LTP. Further collaboration is being discussed between CIP and Kernel CI, and we will update as we progress in the future. So let me conclude today's talk. CIP Kernel team follows up-stream-first principles and contributes to upstreams. CIP opensource tools are used to facilitate the contribution activities. By taking advantage of Kernel LTS, the team steadily releases CIP SLPS kernels and aims to maintain them for 10-plus years or more. To reduce CIP SLPS kernel release cost, the team is closely working with CIP testing team to build automated testing systems. These activities are not only to provide SLPS kernels for 10-plus years by fulfilling industrial requirements, but also to contribute to upstreams. Recently, more and more people have agreed with us by hearing about the activities. If more people work with us, we can expand the activities more, and we can contribute to other projects more. So please join us if you are interested in. If you'd like to know more, there are links for related information. This page talks about our weekly IRC meetings. It is open to everyone. This page talks about repositories on BitLab. You are here for open-source tools explained by CISANA here. And other information is listed here. That's all from us. Thanks for your time to join this talk. Are there any questions? Hi everyone. Thank you very much for joining this session. I'm Masashi Kudo. I'm shaking hands. Hello, I'm Az. So currently we have a couple of questions here. So the first one is, is every LTS version chosen for SLTS in CIP? Yes, actually, let's see. I can show this slide. So far, we are selecting LTS. Currently, we selected 4.4 and 4.19. Kudo-san, I cannot hear you. Hello, can you hear me? Yes. Okay, sorry. Maybe you have to mute the computer. All right. What I'd like to answer is that instead of picking up every LTS, CIP is selecting some LTSes. So far, we have selected 4.4 and 4.19. We are selecting LTS every two to three years. That's our current policy. Yeah. As you may know, there are six LTS versions now. So the CIP won't choose every version as the SLTS. We will discuss and exchange our idea in the CIP technical steering committee and make the consensus afterward. So as you can see, we have two versions now, not every LTS. Okay, so next question is, how would you recommend someone to get involved in the CIP? Yes, that's a great question. Let's just a moment. Yes, this one. As you know, for industrial devices or systems, there are several requirements. And in order to satisfy those requirements, there are several activities required to do that. And so far, we have listed those activities which we believe that those activities are needed. However, only six of them have selected for us to currently working on. If more members can join, more wider range of activities can be accomplished. In addition to those activities, we are working on the super long-term support project. That's, as Azizan explained, we are currently considering the CIP Colonel Confit that is a member company's reference board target. If people would like to have their own platform or boards to be extended for 10 years, then please join and please work with us. Those boards or platforms can be extended for 10 years by working together. Thank you, Kudo-san. Allow me to add some comments. Yes, please. Thank you. Let me scroll down the slides first. Regarding the question, my answer is it depends. It depends on your interest in which kind of the activity. So basically, I would suggest to join the CIP IRC meeting. It's a public IRC channel, and we have a regular meeting every Thursday. So I would recommend if you have interest in CIP activity, feel free to join the CIP IRC weekly meeting. Next question is with Colonel 5.4 version, and later LTS also qualified for SLTS. Yes. As Azizan explained, we discuss about the new SLTS releases at the TSE meetings. And currently, we are going to skip 5.4, and we are going to, probably, we are discussing to select this year's LTS as the next candidate. And therefore, again, 5.4 is skipped at this moment. Yes. Okay. So the next question is, do you publish results merely list? This results mean probably kernel releases, maybe? Then if that is the case, yes. We are announcing our CIP kernel releases in CIP Dev mailing list. Yes, here. At the top line, you can see CIP mailing list, CIP Dev. This is the mailing list. You can see our announcement of our kernel releases. Yes. Regarding the kernel development, the CIP kernel team will work with the upstream. That is stable kernel. So you may find some contribution from CIP members in the stable kernel mailing list. And as the kudos are mentioned, every result will be public in the CIP Dev mailing list as well. So you can refer to below link in this slide. Okay. So next question is, there are any remarkable features you are expected to currently release kernels but not yet in any SLTS? Let's see. This one. Okay. Remarkable features. Yes. This is a little bit controversy, but one thing which is very difficult to achieve is function safety. And at this moment, there are several projects working on the function safety, but at this moment we are not incorporating such a functionality yet. So that's one area we may need to consider. Is this and do you have any comments? Yeah. We welcome every feedback from everyone. Yeah. Okay. So next question is, is there interest in the CIP kernel for automotive applications? This is also a very interesting question. And also, let's see, the area automotive applications seeking is, one functionality is function safety. And that is hard to see. A little bit difficult part we can address. But yes, because automotive Linux also requires long-term support. And myself, I myself is interested in the automotive area. Is this and do we have any comments? Yeah, I agree with you. Since the automotive application needs maybe functional safety or security features. Yeah, so maybe in the future, right? Yeah. Okay. The next question, what sort of industries customers are most interested in SLTS? When I visit customers, they are interested in several areas. Not only super long-term support, but also IoT patches or other features as well. And let's see, those customers, users include the, how to say, MFP, camera, factory automation, and of course, automotive area as well. There are various areas. There are various customers from various industries or various segments are requiring SLTS. It's super long-term support at this moment. Is this and do you have any comments? Yeah, from my personal experience, the customer needs longevity products in some vertical market such as a railway, power plant, oil and gas, et cetera. They have to maintain the system for a long time. So, yeah, they need it. Okay, so next question is, how did you choose 10 years as the support lifetime? Yes, frankly speaking, 10 years is not enough for those customers. Usually 15 years or 20 years are requested, but by looking at the state of the arts of maintenance technology or our community activity, we are going, we are starting with 10 years. By, how to say, by refining methodology and policies, we can extend such 10 years to 12 or 15 years. But at this moment, we are working on 10 years as a first super long activity. Yeah, as you may know, it took lots of resources for maintaining the NINUS kernel. So 10 years is just as Kudo-san mentioned, just a number for us now. Okay, so we only got 20 seconds left. So we don't have enough time for answering the question. Anyway, if you have any questions, I think you can reach us via the mailing list. Right, Kudo-san? Yes, we are welcoming you to join. So we are looking forward to hearing from you more. Okay, thank you. Then again, thanks very much for having joined our session and have a great time in this event. Then bye-bye. See you, bye-bye.