Word count: 5966, reading time approximately: 10 minutesRecently, the Euler community released this year’s innovative version openEuler 22.09. As the first innovative version contributed by the Euler community to the OpenAtom Foundation, this version adds 20.12 million lines of code, of which 48,000 lines are new in the Linux kernel, bringing the total code to 670 million lines!
openEuler adopts a release method that alternates between Long-Term Support (LTS) versions and innovative versions, releasing an LTS version every two years and an innovative version every six months to introduce experimental technical features. This release of openEuler 22.09 comes with quite a few innovative features. However, the official announcement from the Euler community did not provide a particularly detailed introduction to these features, so I specially invited Xiong Wei, Chief Architect of Huawei Server OS and a member of the openEuler Community Technical Committee, to interpret some of the latest and coolest technical features in this release for us.
Starting from the kernel
The announcement of the openEuler 22.09 release mentioned several technical features, such as programmable kernel, distributed soft bus, and embedded hard real-time. These new terms give a sense of familiarity, yet the mysteries remain unclear. As an expert on the Euler Technical Committee, Xiong Wei provided his answers to my curiosity:
What is a programmable kernel?
“The term ‘programmable kernel’ is the one I find most confusing — isn’t the kernel code? It must be produced by programming, so what does ‘programmable’ mean?
In response, Xiong Wei first explained the background of the emergence of the ‘programmable kernel’: “The current hardware iterations change very quickly, but relatively speaking, software changes lag behind. For example, the typical lifecycle of a chip is three years; you spend a year uploading it upstream, it enters the kernel community after half a year, and there is still a long cycle from the community to the users. The fundamental reason is that the kernel is relatively fixed; once developed, after being compiled into a kernel module, it remains relatively fixed.” Therefore, openEuler innovatively borrowed the idea of eBPF, separating the mechanism and the framework, embedding the framework into the kernel, while the implemented functions and strategies only need to be written and injected into the kernel.
In implementation, there are mainly two aspects:
Most of the code in the Linux kernel consists of drivers. Xiong Wei said, “We have an idea: can we also extract kernel drivers? Currently, drivers are too tightly bound to the Linux kernel; can we make kernel drivers also changeable?” In other words, reducing the relationship between driver evolution and Linux kernel versions as much as possible, allowing the kernel version to evolve continuously while drivers can be reused across several major versions, rather than requiring all kernel drivers to be retested, validated, or even redeveloped every time there is a slight change in the kernel.
Regarding the development plan for the ‘programmable kernel’, Xiong Wei stated, “Starting from now, we hope to launch a relatively complete framework by the second half of next year.”
This led me to think: we know that all parts of the kernel are modular; not only can different modules be selected and configured when compiling the kernel, but they can also be dynamically loaded at runtime as needed. So, what is the relationship and difference between ‘programmable kernel’ and kernel modularity?
Xiong Wei explained that kernel modules are not ‘completely changeable’; these kernel modules (KO) are fixed once inserted into the kernel and cannot change during runtime. In contrast, the ‘programmable kernel’ can be flexibly and dynamically adjusted. Furthermore, not only are modules dynamically loaded, but also strategies can be provided dynamically to them. For example, different kernel schedulers can be used based on running business needs, as big data and databases have different scheduling requirements from the kernel.
I am very much looking forward to seeing this kind of innovation at the underlying mechanism level of the kernel, rather than just certain kernel drivers or subsystems, mature and find more applications in subsequent versions.
What is a distributed soft bus?
In recent versions, openEuler mentioned a ‘distributed soft bus’. Some may have seen this term in the HarmonyOS; does this signify further integration between Euler and Harmony?
Xiong Wei said that openEuler’s ‘distributed soft bus’ comes from HarmonyOS. The ‘soft bus’ is the foundation for Harmony’s interconnectivity, automatic discovery, automatic identification, automatic authentication, and automatic connectivity. When translated, this means that any device based on openEuler and all devices based on HarmonyOS can achieve the same features. The previous version of openEuler has already begun to implement the ‘distributed soft bus’, and this version has basically completed it.
The infrastructure work of the ‘distributed soft bus’ serves as a ‘foundation’ for interesting applications and scenarios to emerge, and we look forward to partners and users to explore.
What is embedded hard real-time?
I also noticed that this time openEuler 22.09 mentioned ’embedded hard real-time’; does this mean that RTLinux’s components have been integrated into openEuler?
Xiong Wei first clarified the term ‘hard real-time’: hard real-time capability is a general term, and there is no clear definition of how real-time it must be to be called ‘hard’. Real-time is generally divided into three levels:
The first level is the standard Linux kernel. Currently, the chip processing capability is relatively fast; as long as a certain response speed is achieved, general Linux can meet most real-time requirements.
The second level is to patch the kernel with RTLinux, which has stronger real-time performance than the standard Linux kernel.
However, the third level has particularly strict real-time requirements. For example, the braking system of a car currently cannot meet the relevant requirements with Linux, and there are also compliance challenges, so in general, specialized real-time operating systems are used in such scenarios. In this regard, the Euler community accommodates multiple different kernels, not just the Linux kernel, but also the Zephyr kernel and a small real-time kernel contributed by Huawei, uniproton, etc. Additionally, Euler is collaborating with domestic real-time operating systems like RT-Thread and Wingtech.
In light of the complex scenarios, the community is currently working on a hybrid deployment solution. For example, a chip or SOC with eight cores can allocate two cores for hard real-time work, running real-time kernels like RT-Thread and Wingtech, while the other six cores can run openEuler’s Linux version. A communication mechanism can be built between the two, allowing them to interact. The real-time part handles real-time tasks, while the non-real-time part fully utilizes Linux’s vast ecosystem, and the two can communicate through standardized semantics, thus accommodating various scenario needs. Xiong Wei stated that this part is still under development and should have examples available by the end of this year or early next year.
Support for architectures
According to information disclosed by the Euler community, openEuler supports five architectures: x86, ARM, Shenwei, Loongson, and RISC-V, and supports many chips from various manufacturers, as well as multiple models of complete machines and boards released by several hardware manufacturers, supporting seven types of boards: network cards, RAID, FC, GPU & AI, DPU, SSD, and security cards, with good compatibility.
Support for domestic architectures like Loongson and Shenwei is a given. In addition, with the kernel’s support for Raspberry Pi, various Linux distributions, including openEuler, are also providing support for the latest Raspberry Pi boards.
Furthermore, openEuler’s support for RISC-V has attracted industry attention. RISC-V is known as the Linux of hardware, widely sought after in the open-source community due to its openness. Regarding RISC-V support, Xiong Wei stated that for single-board products, RISC-V’s maturity is already relatively high, but for applications beyond edge computing, such as servers and desktops, there is still a significant gap. Compiling thousands of software packages of the Euler operating system on RISC-V is a considerable challenge. However, passing the compilation is just the first step; the second step is to ensure it can run, and the third step is to ensure it runs well. Xiong Wei believes that RISC-V still has a long way to go for these second and third steps in the entire Linux industry.
Xiong Wei said, “Last year, we communicated with many domestic RISC-V manufacturers and organized related discussion sessions. The current situation is that everyone is working together to prepare the technical groundwork, and we welcome RISC-V manufacturers to develop related products based on openEuler.”
Support for application scenarios
What is virtualized hybrid deployment, and what is its significance?
Earlier, we mentioned a virtualized hybrid deployment scenario in the embedded hard real-time part, and Xiong Wei elaborated further on future trends. Taking cars as an example, the real-time and non-real-time parts of a car were initially designed separately, with each using different chips and wiring, but this approach is costly and complex. In the future, there may be a trend where all these functions are concentrated on one board or even one SOC, with the SOC divided into different partitions: one for real-time control and one for non-real-time control. The real-time partition handles vehicle control, while the non-real-time partition manages the in-vehicle entertainment system. This demand will arise in many scenarios, and its benefits include reduced costs and easier interaction and information sharing. openEuler has several kernels that will be hybrid deployed through a construction system, using different kernels for different scenarios.
Thus, hybrid deployment may inspire many interesting possibilities. Xiong Wei stated that a prototype for hybrid deployment could be launched by the end of this year, with expectations for it to mature next year.
Support for cloud computing/server scenarios
In terms of support for cloud computing and server scenarios, in addition to support for the latest Intel hardware, openEuler has also made considerable efforts in cloud-native and hybrid deployment, such as offline/online hybrid deployment, enhancing resource utilization. Xiong Wei stated that cloud and cloud-native directions are key focuses for openEuler.
Additionally, Xiong Wei mentioned an interesting new initialization system. We know that the original Linux initialization system, such as sysVinit, has largely been replaced by systemd. Although systemd has brought many new advancements, it has also been criticized for being opaque, unwieldy, and monolithic, which contradicts UNIX traditional thinking. Therefore, the Euler community is also developing a new lightweight initialization system called SysMaster, which is being developed in Rust and is planned to be initially applied in embedded and container environments. Xiong Wei stated that a prototype system will be released by the end of this year, with expectations for it to support more scenarios in the future.
Of course, in the openEuler community, SysMaster and systemd can be chosen according to customer requirements, providing better performance and lighter resource usage in specific scenarios. Xiong Wei also expressed the design philosophy of the Euler operating system: “Following this line, much of the work done by openEuler aims to simplify the components of the operating system as much as possible, rather than making them more complex. Doing too much is a negative impact on the operating system.”
Some may view the technical community’s tendency to reinvent the wheel with skepticism, but Xiong Wei said, “We strongly encourage everyone to reinvent the wheel. Only by reinventing the wheel and making better wheels can we continually promote technological progress. For example, the OpenSSL issues are considerable; if someone rewrites the SSL implementation in Rust or another language, we would be very willing to support it and integrate it into our operating system.”
Support provided by Euler for developers
From the data announced this time, the number of developers and contributors in the Euler community has grown rapidly. A total of 1265 developers participated in the contributions for the openEuler 22.09 version, which is a 63% increase compared to the previous version, making it the version with the most developers involved in the history of openEuler.
In this regard, I discussed with Xiong Wei what support the Euler community has provided to developers to encourage so many developers and contributors to participate. Xiong Wei expressed great interest in this topic. He believes that comparing with operating system communities like Debian and Fedora, before openEuler or even in its early stages, there was no complete operating system community in China.
In the early stages, the Euler community was formed by the combined efforts of various manufacturers, including Huawei, but frankly speaking, the initial phase was more about sheer manpower. Xiong Wei stated that from this year, openEuler has started to establish some comprehensive mechanisms for the community and is reconstructing its infrastructure. For example, establishing a unified account; previously, developers needed to register an account on Gitee to contribute to the openEuler operating system, which prevented GitHub developers from participating. Therefore, Euler first needed a unified account to make this infrastructure distributed, without being forced to bind to any specific hosting platform. Through a distributed platform and unified tools, developers can pull from different platforms into one build repository for construction.
This transformation of the entire infrastructure has significantly changed the game, extracting public capabilities to adapt to different platforms, allowing personal development activities to be isolated from platform binding. This approach has great benefits, not only pooling the strength of several manufacturers but also allowing more individual developers to participate. This makes the operation of the entire community more decentralized and also facilitates internationalization. Xiong Wei stated that after the infrastructure transformation is completed, some automation tools, including dashboards, visualization, and quantifiable evaluation systems, will be established, providing a solid foundation for the community’s future internationalization and expansion.
I was particularly encouraged by this information. I have been observing how the Euler community has developed, and I believe this is a significant driving force for future development.
At this point, Xiong Wei also mentioned, “Everyone complains about many things in the community, and we hear it all. The technical committee is aware of everything. However, many issues are complex, and the workload is substantial, requiring orderly improvements step by step. We certainly have a clear plan for the evolution of the entire community, and it will be realized, but everyone may need to be a little patient, as it cannot happen overnight.”
The blueprint for the next version
Subsequently, Xiong Wei discussed the blueprint for future versions. The community is also discussing how to better align the development rhythm of the community with the product iteration speed of upstream and downstream enterprises.
From the current plan, the Euler community hopes to achieve full-scenario and full-coverage in the next LTS version, truly connecting everything from embedded and edge computing to servers and cloud computing. Currently, the full scenario is still relatively primitive, with components only able to connect, and from a construction and infrastructure perspective, they are still relatively separate components. Xiong Wei stated, “At least from my perspective, the most important thing is to turn the entire system into a large system rather than a collection of separate systems.”
In addition, Euler also hopes to complete the distributed and internationalized infrastructure in the next LTS version. This is the two most important things for the community as a whole. Xiong Wei stated that as long as the operational infrastructure is good, the output will not be poor, but if the operational infrastructure is poor, and if it continues to rely on manpower, it will be unsustainable, as the community has grown too large to continue in that manner.
Finally, Xiong Wei shared his views on foundational work: “What we do is not only difficult, costly, and slow to yield results. The work beneath the surface may not be so obvious, but in reality, it is the foundation of our industry.”
