 for attending my presentations. So let me start my presentations. My presentation title is Super Long-Term Support, SLTS, Carnet, and Base Layer Development in the Civil Infrastructure Platform. My name is Yoshitake Kobayashi. Just call me Yoshi, and I'm from our CIP project. At the beginning of my presentations, I would like to say our civilization is run by Linux. So there are some examples. For example, transportation, such as a vehicle control systems, runs on Linux. And for energy power plants, for example, turbine control is already run on Linux. And for industrial systems, industrial automation, and industrial communications, and some other stuff runs on Linux, and health care, and build interventions, and many kinds of stuff which relate on civil infrastructure runs on Linux. But there are some issues to be solved. I would like to mention about one example in a railway system. A railway system, once we build up these kind of systems, it has to survive 25 to 50 years. When we create these railway systems, we have three to five years development time. Within this development time, we spent two to four years for customer-specific extensions. And then one year initial safety certification and authorizations, which means if Linux kernel supports, for example, LTS, it's already expired. So after we release, we also provide some pull-up releases to fix critical bugs, or sometimes add some features. But in that case, we also need to spend three to six months for safety certification and authorizations. And then the systems have to survive 25 or 50 years. This is just an example. And what we've done on the Linux for civil infrastructure system is we improve our real-time capability, and real-time performance, and test a lot. We also improve reliability and the test a lot. And we also create a lot of documents for open-source software license compliance and export control cross-creations, of course. Then we support for a long time, such as 20 to sometimes 60 years. So we have a big problem. The problem we face is that kind of systems has to be support for a very long time. And currently, this kind of super long-term support done by individual companies. So it means each company spends a lot of effort to provide a long-term support. And on the other hand, their systems not only have survived a long time, but also we have to have an industrial grade, which includes robustness, secure, and reliable systems. And now we also need to catch up with the latest technology trends, such as IoT. So the solution we need is, of course, that kind of systems has to have long-term maintenance period, but also have industrial grade. Currently, we are doing individually, but most of effort can be shared by each related companies. So our solution is collaborative development. So we need a collaborative framework to maintain same open source basis system for many, many years to keep secure, robustness, and reliable. And this kind of effort, we also would like to collaborate in the upstream communities. Because upstream, first policy is quite important policy for us, because if we have local changes, we will face our local issues. We would like to share common issues with upstream projects. So CIP is our solution. So CIP aims to establish an open source base layer, which have industrial grade. So this sentence on the top page of CIP project website. So our requirements for civilian infrastructure systems are mainly categorized three parts. First part is industrial grade, which have reliability and functional safety and security and real-time capabilities and stuff, something like that. And of course, we have sustainability for a longer time period. And currently, civilian infrastructure system have unfortunately very conservative upgrade and maintenance strategies, because we don't want to make new issues by upgrading systems. So we have to make sure what kind of changes has been made to fix this kind of bug or something like that. So we would like to share this kind of development costs and also maintenance costs to minimize possible. So if we succeed to share this kind of effort, we are also able to make shorter development time for each systems. So we try to create an open source base layer. This slide shows what the open source base layer is. So open source base layer means open source base reference implementations, which includes a super long time supported kernel and minimized user land at the beginning. So this minimized environment can be used with other packages. But if we try to support whole set of the distribution, it's quite difficult for that. We first would like to focus very critical part for our requirements. So this slide shows our scope of activities. CIP have established on April last year. So it's about 10 months now. And most of people, I think, currently consider CIP is just a long-term supported project. But actually, we are considering a lot of technical issues such as real-time stuff. So at the beginning, we also created this kind of technical map, which includes many technical topics. And what kind of topics can be collaborate with other open source projects? And what kind of topics has to be considered by CIP inside? So this kind of stuff is keeping updated. But I would like to focus on a simplified one. And currently, we are focusing on this red part. The first month, of course, we started from the long-term support at the initial effort. And then extend to the test automations because testing is quite important for our use case to survive the systems for a long time. And then we also are currently focusing on strong interest in the real-time support stuff. So current status of the CIP base layer development is considered two parts. One part is a CIP super long-term supported current. So we have already decided CIP current version as 4.4. 4.4 is an initial CIP current version which supports super long time. And this support current supported by a maintenance by hatching is an initial CIP current maintenance. So he has a lot of experience to maintain a current for a long time. And we also define current maintenance policies, which is already documented in the CIP Wiki site. So because we need to define our own maintenance policies, otherwise we just get some issues in the future. And we already started maintenance. Linux 4.4.48, that's CIP2, has already released on the 10th of February, so about two weeks ago. And now we are creating a CIP current test framework to continue testing. For the CIP core package development, we consider four steps. At first, we define an initial component set, then component versions. And also, if we need to have some features, we also contribute to upstream project, then maintain. But now we just at the beginning. So the following slide, I would like to describe CIP's SLTS current development and CIP testing, and also base layer developments. So first, CIP SLTS current development. So this is an overview of the CIP SLT current development. For CIP SLTS, we plan to have two trees. One tree is for CIP SLTS, which is the official CIP SLTS current tree, which is available on the kernel.org under the Bayhatching directory. And this is based on the Linux stable kernels. Currently, this is maintained by Greg Rowe Hartman. And so, but CIP kernel maintainer is Bayhatching, because we have some back-ported features on top of the stable kernel tree. So this CIP stable kernel tree, validated by CIP. And the second tree is CIP SLTS plus preempt RT patches. We plan to have these trees, because most of systems depend on preempt RT, because most of the products should have real-time capabilities. So this CIP kernel tree, we based on the stable RT and also CIP back-ported features. And this is separately maintained by CIP members country. So the maintenance period we are currently planning is at least 10 years or more. Sometimes we need 20 years maintenance period, but it depends on our requirements. So this is an initial requirement for CIP SLTS kernel. And this is what describes the kernel development trees. Currently, on the main line, the stable kernel tree 4.4 is already an LTS kernel. But this LTS kernel will be stopped to maintain for several years later. After that, we would like to take over from this kernel from the maintenance. And this CIP kernel have some back-ported features from the upstream and maintained by pen hatching. And based on this one and preempt RT, we also have a stable RT base branch. So this is also validated by CIP members. So once we start maintaining our IOSS, which means LTS kernel already two years old or more, which means most of the features difficult to back-port. So we're considering to back-port some features for maybe two years. But after two or three years later, we stop and focus to security fix only. And we decided to currently maintain a spreadsheet which is available on the CIP website. And I can show you this is available on the CIP website. But this is a bit longer. And I summarize this maintenance process. We basically follow the stable kernel development rule. But the difference in between the stable kernel and CIP kernel is we accept the back-ported features. However, we accepted the back-ported features. All features have to be upstreamed before back-start back-porting. This is very important policies, because if we just take some out-of-tree patches, but after that, probably this kind of patches will become part of upstream. So it caused serious conflict in between that. So we don't want to make this kind of conflict in the CIP kernels. So this is why we consider CIP, consider upstream first policy is important. And, yeah, of course, validation will be done by CIP infrastructures. And current back-ported features on CIP 4.4 CIP is related on the kernel self-protection projects features. So these three features have already back-ported to CIP kernels, because our security is quite important issues for us in the future. So this is why we decide back-ported from the KSPP project. So this kind of future, of course, already upstreamed. So this is why also we decided to do that. So I would like to mention about also out-of-tree drivers. In general, all out-of-tree drivers are unsupported by CIP. However, of course, users can use CIP kernel with out-of-tree drivers at your own risk. So if someone use out-of-tree drivers with CIP kernel, please make sure when you find some bugs on your own CIP modified kernel, that issues is also on the CIP original kernel or not. Otherwise, we cannot answer these kind of questions. So this is quite important for us. But even a user can use CIP kernel to at your own risk, but there are some barriers because we direct to focus on security fixes which support for 10 years. So which means that kind of effort can be shared even the out-of-tree included by your own local tree or something. So our major version is cycle we are considering next SLTS kernel version, but it's too early to announce because if we release one SLTS kernel every year and then support it more than 10 years, which means after 10 years, we have to support 10 branches. So it's unable to do that by one person or two persons. We have a limited, of course, a limited budget. We also direct to spend more on other activities. So we just said CIP will take next LTS kernel every two to four years. And as you know, CIP also allows some future backports. But there is one project called LTSI, Long-Term Support Initiative Project. They also allow to backport to the LTS versions. So we don't reinvent this kind of effort for next time because 4.4 is unfortunately not LTSI kernel version because LTSI project skipped last year, but we decided kernel version last year. But next versions, we're planning to synchronize with LTSI to backporting efforts. So this is overall of the SLTS kernel development. So next topic is CIP testing. So the purpose of CIP testing is not so much different between the other projects. We direct to detecting bugs, and we direct to detecting regressions for future and also performance regressions. And of course, important is provide test results in a timely manner. So we direct to keep continue testing on the SLTS versions. So we define four milestones. At the beginning, we direct to start setup for a single developer, which means a single developer can test their SLTS kernel on the desk with their development board. So these are first milestones. Yeah. And next milestone is CIP kernel testing. Of course, we start a regular basis testing and then share results with other CIP community members. And after that, we define a kernel testing as a substance in CIP and then first three milestones focusing on kernel testing. And after that, we also consider to extend from the kernel testing to system testing. So this is also documented on our wiki. If you are interested in the more details, please go to our wiki sites. And current status is almost done for first milestone. So I can say in between one and two now. So the first milestone is a board up desk for single developer. The goal for this milestone is to create and publish a VM image that contains kernel CI and Lava 2. And this kind of VM image can be used by single developer to test a CIP kernel or, of course, other kernels. And current status is kernel CI and Lava have been merged into one VM. Actually, kernel CI runs on something, a Brunt or Debian, and Lava runs on the Debian and Brunt. I'm difficult to match, but we solved these kind of issues. And now beta version just released a half hour ago. OK, yeah. If you go to a CIP development mailing list, you can find the post. And all source calls are available on the CIP GitHub project website. So what we considered for the next step is we also collaborate with other testing projects, such as, of course, kernel CI and Lava and Fuego. Because currently, we fork kernel CI and Lava and put it into the one VM. But unfortunately, currently, we have local changes. So we would like to contribute to such kind of changes to upstream project, of course. And also, currently, kernel CI and Lava on kernel CI projects are mainly focusing on the Brunt tests or development tests. But we would like to extend these kind of tests or more flexible. Maybe we can collaborate with Fuego with this purpose. So CIP members will plan to join Fuego Boss. It will be held tomorrow at lunchtime, maybe around lunchtime, at the same place. So please come here for testing tomorrow. So we would like to discuss more deeply how to collaborate with each other. So this is a very recent development status for CIP kernel testing. And now I move to CIP core package development. So at the beginning, there are four milestones, as I said. We started to define an initial component set. As I said, our base layer includes minimum components set at the beginning. So an initial component set has to be smaller as possible. And of course, current situation, current status is milestone one. The reason why I put one line in between one and two is I think there are huge gaps in between that. So to decide the component version, we should talk with upstream maintainer at the beginning. So this is not done by yet. So before deciding current component versions, we would like to talk to upstream maintainer. But yeah, I can show you what is our initial component set for CIP base layer. So this is quite simple. Of course, we have a CIP SLTS kernel with a preemptive patch and back for the futures. And on the user and other part of that, we should have bootloader and UTTs and base library, a toolchain, and security staffs. So this is our initial base layer. But to development this kind of base layer, we also consider to keep development packages for reproducible bits. But we consider this kind of development package is not part of super long term support. Maybe we should focus on the core packages. And unfortunately, we didn't decide it any component version yet. But we decided to start CIP project X. All right. Please, please. The question is, how long will we support for this kind of component? So currently, I will consider it as the same as super long term support current release. This is why it makes difficult to decide the component versions. So yeah. Is it OK with that? OK. So yeah, CIP decides to start project X. So this is just a tentative name. But we started an incubation project for minimum base systems. This project will provide the way to test the installable image. So the goal is, first, we use Debian source code and the CIP kernel as input. And then build an installable image by using a bitback or Debian build systems. And output is a minimum deployable base systems. So we try to create this deployable image at the beginning. So this is just started. So our development plan is showing on this slide. I usually use this slide. So this is just initial state. Now we make our base layer as minimized as possible. But we try to extend this base layer to fit our requirements. So first step is just defined, initial set. Then, yeah, support more packages later. So I will summarize my presentations before going to the latter part of my presentations. So we have already selected the first CIP kernel as 4.4. And we also decided the initial maintainer as Ben Hatchin. And we also defined CIP kernel maintenance policies. It is available on the CIP website. And we also developed an initial board platform and defined platform to provide support for them. Currently, we are using a big-worn block and LUNESUS boards in near future for the initial board sets. Because most of the member companies using such kind of chipsets. So we also developed a CIP kernel testing. As the name of the board at desk, single development, it's available on the website. And also, we started CIP Project X. This is our latest development status of the CIP inside our project. So let me explain what's next step. So the next step by CIP, we would like to extend board at desk in single developer. Currently, just my kernel CI and Lava 2 into one versions. So which means just testing for boot testing and build testing on something like that. So we would like to increase the testing coverage to define milestone 2. And of course, we would like to improve integrations with other testing projects, something like Flego and Lava. We started discussing with CIP Project. And for the kernel maintenance, we just started the kernel maintenance. So this is the first year for our experience. So to extend our kernel maintenance, we also defined our next step, what we need for kernel maintenance. And for core package development, which includes a base layer, we also have to be analyze many packages and also discussing with our upstream maintenance as part of CIP base layer. So to do that, we would like to collaborate with upstream project, something like kernel CI of Flego and ER2038 project. This is quite an important issue for us on the kernel self-protection project and also real-time Linux workgroup. So if you're interested in this kind of effort, please join us. So after that, maybe something like promotion. So why join CIP? Of course, we are collaborative projects. Membership is needed to join that. But the value of membership is if you join our project, the members still participate in project decisions and technical decisions, what we need for CIP infrastructure systems. Of course, we participate to bring your use cases and ideas in the right form and can be contribute with upstream project with other members and also can be learn how to contribute with upstream project. And last collaboration, we can share the knowledge and effort, each other. Yeah, this is a quite big value for us. So please feel free contact us. So if you're interested in our membership, please contact the Linux Foundation. This is our contact person in the Linux Foundation. But in the other words, we have many public resources available, which includes the CIP mailing list, development mailing list. This is a public mailing list. So please contact, please feel free contact what we need or what kind of issues you have or what you want to do or something like that. Any comment is welcome for us. So call for new positions. Overall, CIP provides super long-term maintained industrial-grade embedded Linux platform. So current member is Hitachi Shimes, Lunesas and Toshiba. And Lunesas just joined last month. This is Lunesas is a fast SOC vendor in the CIP project. And the CIP member is Codesync and Platform. So we joined together to provide super long-term supported embedded platform. So this is overall my presentation. So any questions? Yeah, please. Let's say you're in that stream, it will be also very difficult. Testing your kernel, testing the other kernel, they're so diverged, it's a really hard problem, right? Obviously, you can always just throw a lot of effort at it. You can just try really hard. It's a very difficult thing. Do you have any strategies or thoughts for how to make that easier, especially three years in, kind of easy, five years, five, 10 years it's getting higher between 20, really, really high. So the question is, if we continue to maintain for super long time, after several years, we are difficult to upstream our parties to upstream. But how to solve these kind of issues? Is that the answer? It's only in the backboard. Yeah. So yeah, we don't want to maintain by ourselves. At first, we should have these kind of fixes upstream first, then backboard it, not the other directions. But yeah, of course, after several years, we will face difficulties to backboarding from the upstream project. Currently, we don't have correct answers. But for example, experienced maintainers have already done that for many years. So currently, we consider to ask these kind of maintainers to have some backboarding. Or yeah. Well? Yeah. Yeah. We only say like, well-fired. But 20 years is where I think the point is that the party at the car today is not really predictable. So let's see how probably you can get beyond the chair. That is a realistic post-democracy. So anybody who can look at the current 10-year old, that was actually not bad. There was another maintainer who was maintaining 2.4. So it happened. Got you. Great. I think there's a point where it is no longer backboard on the right-board. Yeah. It's like rewriting. Yeah. Yeah. Yeah. You think about something at a higher level than the code. You're saying this content is still applied to me or not. Yeah. I mean, think about it. These companies are going to do this. Better to do it together now. Yeah. Yeah. So please. Mm-hmm. Does that include platform, faculty, or some new platform that's not present in 4.4? So that depends on our requirements. Yeah. But most of the features are not, yeah, belongs to Isochi backboards probably. Because we have to, yeah. So if the kind of backboard is concretely, yeah, separate it into other parts, maybe easy to backboard. But otherwise, we don't want to have serious issues for that. Yeah. Please. Right. Mm-hmm. Why are you not trying to standardize the loader as well? Yeah, we have a bootloader. Are you a bootloader? Yeah. So the question is, yeah, yeah, we have a bootloader, but we also have, you know, we also maintain that's a bootloader for a long time. Is it correct? Yeah. Okay. Yeah. So we are, sometimes a bootloader has serious security issues. We try to fix this kind of security issues for a long time. Yeah. Which means maintain for a long time. Yeah. Please. So I want to evaluate different components, how they stay with their own path, or for instance, that you have any guidelines for that? Okay. The question is, the kernel is quite big, and many configurations are available on that. And to maintain whole stuff is quite difficult. And how to maintain, you know, we, you know, the question is, do we have an idea to maintain that kind of stuff? Yeah. Define scopes. Define scopes. Okay. Yeah. Of course, kernel is quite big stuff. So, but our requirement is limited. So, which means we should define, for example, when we testing the kernel, we should say, this is a tested environment, which includes these features and these features and these features. So this is a tested part. So, the other coverage is not tested yet. So, something like that. So, at the initial state, we would like to define some initial configurations. But later, we would like to extend these kind of components and our feature sets. Yeah. Sorry. Yeah. I couldn't get correct. So, the question is, for example, glibc and the gcc is a part of our maintenance. So, you said, is it able to run for a long time period or not? Is that correct? Yeah. Yeah. I think, yeah, the compatibility, maybe these kind of issues, they are kind of a compatibility issues. Yeah. So, yeah, we don't want to get some regulations in between the fixes. So, this is why we would like to have a continuous testing environment inside the CIP kernel. So, which means we also consider we don't have regulations for our base layer. The question is, will we be freezing a compiler and packaging for everything? Our answer, current answer is, current plan is yes. Yeah. So, please. Okay. The question is, yeah. So, upstream-first policy is a great policy in CIP kernel. But current reality is I accept non-upstream features. So, how to solve this kind of, okay. Yeah. We discussed with the LTSI person yesterday and they currently have upstream-first policy too. So, please. So, we would like to have a continuous testing environment. So, based on the... The question is, are you adding anything to the kernel to support that continuous integration? Oh. Adding capabilities. So, which means, yeah, inside the kernel tree, the question is, yeah, will we be adding some continuous testing inside the kernel? Is that the right question? Right. Understand? Again, I'm trying to understand how you make the judgment. Are you adding new tests? Oh, see. Well, my understanding is let me add a whole bunch of tests, but they're all external to the kernel. So, we're not altering that. I guess what I'm saying is, so we don't do that right now with the kernel. We don't have a test value described without the industry. It's very ad-bocked. Yeah. Yeah. Sorry. Yeah, it's okay. So, yeah, please. We'll try to define this cool thing which is that maybe you are learning to... Mm-hmm. The question is, yeah, currently we're focusing on civil infrastructure, but we also extended under our focus industry. So, what kind of industry will we focus on in the future? So, I think, yeah, our technical scope is not... sometimes not only belongs to the civil infrastructure. Of course, we, yeah, consider to use this kind of stuff in the healthcare stuff and this kind of critical stuff. So, if there are any products need to have industrial-grade quality, yeah, it is kind of focusing on the industry. But... Yeah. So, the comment is, if we extend our focus industry, we will face some conflict in between our requirement or new member requirements. So, in that case, yeah, this is a collaborative project. We have to discuss with these kind of members. So, yeah, we are open to discussing with other members, such as automotive also. Yeah. Please. Yeah. Yeah. Okay. Do you have a moment? Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Oops. Yeah. Oups. And if there's so much commodity in this additional things coming in, you may look into this but you can't promise anything which is unhandable. And I'd say no then say yes of course and then fail. Okay. It may happen. You'll have to see. But of course the ideal case is that we don't have it here. Okay. Okay. Okay. Excuse me. Also time is up I think. So thank you very much for attending my presentations. Thank you.