 Hi, my name is Yoshitake Kobayashi and today I'm talking about the Sibling Fula Structure platform which is an industrial-grade open source base layer. Before I'm starting to talk about CIP, I'd like to explain what CIP is, CIP is one of the most conservative open source project in the Linux foundations. I think this project is one of the most important project for our civilization, civilizations. That's because CIP aims to provide open source base layer for CIP related embedded systems and which runs on the infrastructure stuff. We also work closely with the upstream community, so work with the upstream community is quite important concept for us because without working with the upstream, we cannot become realized through this kind of a concept. So CIP wants to create a base layer, but base layer doesn't mean whole distributions. Whole distribution is quite big, but we would like to concentrate to build very limited important stuff for our embedded use cases. So I'd like to say our civilization runs on Linux, that's real. Many infrastructure related stuff such as transportation and energy or industry and healthcare, something like that, it already runs on Linux. For example, for power plant, turbine is controlling by Linux. So if such kind of stuff just stopped, it caused serious issues for our life. So there are some issues to be solved. For example, I'd like to explain about power plant system example. Once we created power plant, the life cycle is 25 to 60 years. So it's very long time. So when we create power plant, we usually take 3 to 5 years for development. In this development cycle, we also take half year to 4 years for customer specific extensions to fit the customer requirements. And after we release this kind of product, we also supply 6 to 8 years, which means maximum 18 years, 13 years for supply time, including a development time. And then more than 15 years hardware maintenance, oh sorry, after a latest shipment. I'd like to say 20 to 60 years for product life cycle. And I'd like to mention 2 years. What 2 years means? CRP just started from April 2016, which means we're now on 2 years old. But product life cycle, lifetime, is 60 years for the most case. So during this product lifetime, things change a lot. There are one typical example is IoT. IoT means many things connected to the network to optimize our life. And industriality is also a similar concept. And within the industry, even industrial area, many kinds of stuff are connected to the network to keep our infrastructures. And these kinds of stuff need to have industrial grades, quality, and also security management stuff. So this kind of stuff has to be secure enough to continue to provide services. So there are some problems. So in our use case, especially for civilian infrastructure platform case, we need to have very long life support. And currently, this long-term support done by individual companies. So each company doing long-term support. Even their business area is quite similar. And the other problem is we're also doing a lot of effort to create an industrial-grade software and industrial-grade product to have a robustness or secure and reliable. These kinds of stuff also done by individual companies. But we are doing very similar stuff. For example, we would like to have real-time capabilities to control turbines. But the other company also thinking about that. These kinds of stuff can be shared by the companies which have similar concerns. So the solution we need is we have to have long-term maintenance and also industrial-grade. That's two topics can be solved by the collaborations. And CIP is our solution. That's why we started CIP two years ago. And we'd like to establish an open-source base layer of industrial-grade software to ensure the use and implementation of software building blocks for civilian infrastructure systems. And now we have seven companies. And one company, Moxa, is just joined last December. So we try to contribute to the open-source project individually. And also we have a budget to contribute to the other open-source project, which we require to have our use case. This is a very basic concept for the civilian infrastructure systems. Then from an open-source project, we try to collect open-source software by managing CIP and then want to go to long-term support. This is the original concept when we started CIP. And what CIP again is our focus is open-source base layer. Open-source base layer is industrial-grade core open-source software components, which includes Linux kernel and very basic software, something like GDBC or busybox or something like that. And this component is quite important for us, but this can be extended by other distributions because other distributions have a lot of open-source software packages, can be used with CIP open-source base layer. So this concept is very important to realize CIP because CIP have a limited resource and very difficult to create whole distributions. So we started from very small, then extended to a bit and again. So from now, I'd like to explain the latest CIP status and activities. When we started CIP two years ago, we focused... At first, we focused on super long-term support Linux kernels. Then we moved to focus to the testing and real-time and also build environment for CIP base layer. So the first one is the kernel maintenance. We created a super long-term kernel based on Linux kernel stable. And after that, we merged a preempt RT patch on top of the CIP kernel. This is actually based on the stable RT. And after we selected the CIP kernel, we also need to test the kernel. So we created a testing environment, which called a border test. I will explain later. And finally, we created the CIP core, which includes the CIP kernel and the open-source components. So when we started CIP, we need to select the kernel versions. And at that time, we selected the Linux 4.4 as the first CIP long-term support kernel. And we also hired a maintainer from the community. And Ben Hatching is from Cosync, is our CIP super long-term support kernel maintainer. And the Linux 4.4.1.20, CIP-20, it just released on March 9th. So probably most of you related to some development. Maybe 4.4 is LTS, not even a CIP. So what we are doing is CIP not just doing maintenance by ourselves. So we back-boarded some features from the upstream kernel for CIP kernel. But this is very limited to make more secure, to have more board support packages. So one key feature is security. And we back-boarded the kernel-safe protection project-related features. And we also back-boarded patches from Siemens IoT-2000 series. And also, we actually back-porting many patches for UNESCO's RZC series. This kind of feature is now on CIP kernel. And we created the CIP kernel maintenance policy and the most important in our kernel maintenance policy is upstream fast. So if we want to have some future back-port in our CIP kernel, the future must be included in the upstream fast. Then we try to back-board. So I mentioned that some future back-port is already done by CIP. It's actually already on upstream. And now we have around four to six weeks release cycles. But before CIP 120 is released, as you know, there are huge issues on kernel security meltdown spectrum. So we also are investigating a lot and what kind of effects will we have for that. So in that case, yeah, we have a bit longer release cycle. But mostly four to six weeks release cycle done by brain hatching. And we're also working with LTS stable release cycle. For example, a brain hatching review of stable patches. So this is a quite small techies. But Gregor Hartman, just asking, reviewing patches for 4.4. And Ben reviewed and find some patches like that. In this review cycle, there are some patches which delete K-free here. But this delete removable makes memory leak. So Ben Hartman commented to these kind of mistakes. So this kind of work also making more reliable for the stable kernel. And I would like to mention about out of three drivers. We don't have out of three drivers in CIP kernel yet. But of course, this is open source. So anyone wants to have out of three drivers with CIP kernel. But this kind of stuff can be done by themselves. And CIP official kernel do not have any out of three drivers. So now we also need to consider the next CIP LTS kernel versions. At the beginning, starting time, or CIP, I mentioned a CIP kernel will be released every two to three years. And now CIP is two years old. So we are considering to have our next CIP kernel. And most important thing we are considering is kernel version alignment. Now, many projects are using long-term support kernel. So we at least want to select Linux kernel from LTS versions. But the other project also using LTS. For example, LTSI, AGL, and maybe Debian, and more. So we would like to make some alignment with such kind of communities to share the effort for the maintenance. So to make it realize, we are planning to have a face-to-face meeting during Open Source Summit in June with a stable kernel maintainer and also our CIP kernel maintainer. The next thing we are doing is real-time. Most of you know, still real-time Linux patch is not upstream yet. But to make a controller stuff, we need real-time capability. So we are trying to help a real-time Linux project to become a gold member. And currently, we are working together with a real-time Linux project. And Daniel Wabner from Siemens is working to become the maintainer for stable RT kernel. This is the base version of the CIP kernel. And currently, we're discussing how to take over the current maintenance from the Steven Oswet to Daniel after 4.4 maintenance period is done. For more information, you can find this URL. And now, CIP, SLTS kernel is available. And that first CIP real-time kernel was released in January, I think January 2nd. And the latest one is 4.4, 120 CIP, 20 RT something. And it's maintained by Daniel Wabner from Siemens and validated by him and also CIP. And yeah, after we release a CIP kernel, we need to validate a CIP kernel itself. We created the environment for testing kernels. And that's called the Baudat Desk. Baudat Desk designed to test relaxed kernel and base systems locally by using kernel CI and Lava. Kernel CI and Lava is mostly very common tools to test kernels in community. That's why we selected both of two components. But that kind of system usually working on the remotely, but we'd like to test locally to validate our embedded systems. So Baudat Desk able to connect to devices that are on desk. This is a concept why we called Baudat Desk. And this is already available on the GitLab. And you can test by using it Baudat Desk. And recently, we updated Baudat Desk to include the latest kernel CI. And also supporting to Renaissance board. And then we just recently sharing test results by using email mailing list. So if you're going to the CIP test results mailing list, you can find some results by testing done by Baudat Desk. And currently, Baudat Desk, made by Bagramt and Virtual Machine Box. And we direct to development through containers. So this is currently under development. And we also want to collaborate with other testing projects, which is using Lava and Kernel CI. Yesterday, we had a technical showcase. And there are one demonstration which is called a Loving Box. So this is also using Kernel CI and Lava stuffs, just included one box to test both. This kind of work also similar concept with Baudat Desk. So we direct to work together to realize this kind of stuffs. Then the last one is the CIP core packages. So it's just grayed out second step. We define the initial components at first, which include libc, bzbox, uboot, relux kernel, something like that. That was less than 10 components. But after that, we would like to define the component version. But to define component version, it's quite difficult. Because we also would like to work with community. So we decide to contribute upstream projects and decide to Debian as CIP primary reference distributions. Primary reference distribution means CIP will select a CIP core packages from Debian packages. And also CIP will direct to work with Debian community. Recently, the reason why we choose Debian is Debian has wide community. And also Debian has a very clear license cleaning process. And of course, we have already a Debian-based product in some companies. So that's why we chose Debian. And to start collaboration with Debian, we thought long-term support is quite important project. So we decided, and just we decided to support Debian LTS project as a potential label. This is not opened yet because we just decided a few days ago during a CIP governing board meeting. So we started to contribute to Debian LTS and also Debian communities, which related to some security staffs. And yeah, in this, Debian also wants to have some staging repositories to security master. And this is still ongoing project. And it is already on the bug report track. So we let also support this kind of work to be fixed. We are also working for that. So this is OK, skip. And to make a CIP core packages, we also need a build environment. So we created one build environment which have a Debian source code or Debian build packages with CIP kernel to have a minimum deployable base systems. And we call that this software as a CIP core. And current status is we already created tools in this GitHub repository. And some of both include the Renaissance, Big Bone Black, Cyclone 5 staffs is already able to run by using a CIP kernel with Debian source code. Maybe I just skip this. And there are many tools already available by using Debian binary packages or Debian source code. And there are at least three efforts doing similar stuff. So in this kind of stuff could be used by CIP. And currently CIP using a Debian. But this one is based on full source code, not able to get binary packages. So we would like to combine this kind of stuff to make more easy to use to build our root file systems. So this is a tool. And the other way to have a root file systems, of course, we just use Debian itself. But there are some gaps and common goals in between CIP and Debian. As you know, Debian is a very huge distribution, which includes more than 25,000 source packages, which can be generated 67,000 binary packages. But CIP currently focusing less than 10 packages. But the support term is quite different. Kind of Debian only supports five years. But CIP needs to support more than 10 years. That's why we started to contribute to Debian LTS first to consider to extend the support term with Debian community. And for build systems, we sometimes need to have cross build capabilities. But Debian are using native build. So there are some points. We can contribute for Debian cross. And open source license compliance issues, currently Debian moved to a new license format, which is called Dev5. And this is very detailed information and can be converted from SPDX files, which is standardized by Linux Foundation project. So we currently considering to have reviewed result with, for example, SPDX, then convert it to Dev5 and also contribute to Debian community. So this is a kind of way to contribute to Debian. So I also would like to mention some of the CIP members also interested in Yacht project. They want to use BitBake with CIP-based component. So now we decided that Debian are the primary distributions and Debian source code have a five year support. So to have this benefit with Yacht project, we consider to make maybe a meta CIP layer. But this is a kind of ongoing project. So the other stuff under discussion in CIP is we now started considering cybersecurity standards. IEC 26443 is a cybersecurity standard which includes many specifications to develop secure industrial automation and control systems. This standard actually define the processes to develop a secure product. In this process, the specification also requires lots of tests. But currently no standardized test cases are available or we also would like to have this certified product but we still don't study how to get our product ready for the cybersecurity standard. So to realize this kind of stuff, we consider to development test cases and also recommended setting-ups to be documented. If this kind of work to be done by CIP, so CIP users also get the benefit to certify their product for this standard. So that's what we are going to move forward. But we are sure we will not develop a procedure or certification schema because this is done by organizations finally. And question, 20 years from now, do you know? From 20 years we have January 19th, 2038. So this year 2038 is a blocking issue if we want to have our product for more 20 years commitment. So and to solve these issues, there are a lot of stuff needs to be done. And we know someone already working on these issues like and is working for Karnem and the other person working for G-Lib C to solve this year 2038 for issues. So we also had a discussion with them how can we collaborate to solve these issues during the last ELC Europe timing. So yeah, this is currently ongoing, but unfortunately we haven't had any output yet. So we also discussed a lot of stuff. Functional safety and software update for industrial systems is also maybe need to have. But for functional safety, there are also some projects is running like a Syrto-Linux MP or something like that. But this is very difficult issues. So we'd like to, yeah, want to know what they are doing and also we'd like to decide how can we collaborate with them. And this one is not under discussions, but I'd like to say CIP just joined HGX formerly as an associate member. Currently under discussion is what we can do with them because HGX is trying to create middlewares using Docker or containers. But in the below, we are using Linux. And this part also need to be supported securely enough for a longer time by using industrial area. So that's why we become an HGX Foundry associate member. So next time maybe we try to run HGX Foundry component on CIP base layer. But currently CIP base layer have a gap to run HGX Foundry. For example, HGX Foundry require Java. But CIP, I'm sure, currently not includes Java itself. But the Debian component already includes Java. So maybe we can consider to create CIP kernel with CIP base layer and Debian packages, then try to run. This is a might be a story. So I'd like to conclude my presentation. Currently CIP focusing on open source base layer development. And we are focused on several topics, which include kernel maintenance, testing, and CIP core packages. And now we started the security staff. And this kind can be done by collaborations. We already started collaborate with Debian community and real-time start project and HGX Foundry. So we try to extend this kind of collaboration to realize the CIP base layer. So I'd like to conclude my presentations. And I'd like to say our civilizations need an open source base layer of industry-grade software to make more stable for our infrastructure. And CIP will provide this by using Linux. And to realize CIP base layer, we get a sustainability either ensured by backing a big industrial and semiconductor companies, also cross-cooperation with building with mature open source product, such as Debian. And finally, we'd like to say collaboration is one of key concept for CIP. So that's all of my presentation. Thank you very much. Any questions? Yes, please. OK, the question is he's working for the company in Brazil. And in Brazil, CIP is also beneficial to realize their infrastructure. And his question is how can they be involved to CIP? That's all. I think, yeah, please join. Yeah. Yeah. And this is also, of course, this is open source project. You can ask us any contribution to CIP project. And we have an open mailing list, which is open for everyone, not just limited to the CIP members. We have our WIC page, which includes how to, for example, how to build CIP core, and how to use the CIP kernel, something like that. So I would like to provide this kind of information. Maybe I have some. Hang on a sec. All right. 54. No, no, no. 54. No? 54. Sorry. Maybe I need to finish my presentation first. Then, OK, this is the information you can get there. Yeah, I will upload with this information to the sketch.org. OK, thank you very much. And any other questions? All right. OK. That's a good question. And his question is, yeah, we have an upstream policy. Even we have an upstream policy, the changes for kernel is made every day. And after six years or 10 years, they will change a lot, which include API changes or something like that. In that case, even we have an upstream first policy, we are very difficult to backport from the upstream. And his question is, what do we think about upstream policy? Even this kind of stuff happens. And my answer is, we know this kind of issues will become real. But if we, no, just, sorry, this is in my opinion. Even that, if we consider the upstream first, we know what upstream thinking and what is the most important way to backport it. Even this is quite difficult. So sometimes we have to make two drivers for upstream and downstream. But maybe a concept, some part of the concept for the development could be shared by each other. Yeah. Yeah. Yeah. Please make a bit loud voice. Yeah, I cannot hear your voice. So there are some possible cases will be happened. Even we have an upstream policy, we have to consider to case by case basis. So that is his comment. And yeah. So this kind, yeah, I understand that. But in that case, that kind of stuff is probably out of tree. And also specific to the developer. So need to be supported by themself. So we direct to have a CIP corner itself and keep it stable. So which means the developer also can be maintained with that CIP corner. Even after the original stable is already unsupported, we have to support CIP corner. So that kind of things can be done, I think. So any other comment or questions? Yes, please. OK, the question is, do I have a summary to show CIP version and release timing? And the answer is, sorry, I don't have. And yeah, we can check the Git log to get the summary. But currently, we don't have a page to summarize that. Ah, I see. OK, that's a good comment. Thank you very much. Yeah, and someone asked me why we are saying CIP corner is supported by 10 years. Why don't we ask karnel.org to show the release pages or something? This is a might be we have to consider. But yeah, currently, we have a backport package. So we should consider what can be done. All right, thank you very much. And other questions? Comment? All right, it's more time. Thank you very much for attending.