A method and apparatus for porting the open-source HarmonyOS system to the Linux kernel.

Abstract

This invention discloses a method and apparatus for porting the open-source HarmonyOS system to a Linux kernel. The method includes: obtaining adaptation layer code built based on kernel features of the open-source HarmonyOS framework; performing HarmonyOS-ization on the Linux kernel of the target board to obtain a kernel image file; compiling the adaptation layer code and the target code of the open-source HarmonyOS system based on kernel compilation parameters and target compilation tools to obtain a target image file; and starting the open-source HarmonyOS system on the target board based on the kernel image file and the target image file. The technical solution of this invention can support Linux, Android, and OpenHarmony systems simultaneously with a single kernel codebase, significantly reducing labor costs and shortening the development cycle.

Description

Technical Field

[0001] This invention relates to the field of board development technology, and in particular to a method and apparatus for porting the open-source HarmonyOS system to the Linux kernel. Background Technology

[0002] Currently, most board hardware manufacturers have their own Linux kernels adapted for Linux and Android systems. However, these versions often differ significantly from the Linux kernel provided by the OpenHarmony (open-source HarmonyOS) community, making them unable to support the features of the OpenHarmony system. For hardware manufacturers to run OpenHarmony, they typically need to re-adapt their board drivers to the OpenHarmony community's Linux kernel. This re-adaptation is repetitive and labor-intensive, adding weeks or even months to the development workload. Furthermore, it requires maintaining an additional Linux kernel codebase adapted for OpenHarmony in the long term, doubling development manpower, costs, and timelines.

[0003] In the current process of adapting OpenHarmony to the south, the existing Linux and Android driver adaptation work of board manufacturers cannot be directly reused. Hardware adaptation is done on the Linux kernel version of the OpenHarmony community, which is a time-consuming and labor-intensive repetitive development work. This makes the technical threshold and economic cost of OpenHarmony high, which to some extent hinders the formation of the OpenHarmony ecosystem. Summary of the Invention

[0004] This invention provides a method and apparatus for porting the Linux kernel to the open-source Harmony system, in order to solve the problems of long development time and high maintenance cost for board manufacturers to adapt to the OpenHarmony system.

[0005] According to one aspect of the present invention, a method for porting the open-source HarmonyOS system to the Linux kernel is provided, comprising:

[0006] Obtain the adaptation layer code built based on the kernel features of the open-source HarmonyOS system framework;

[0007] The kernel code of the target board's Linux kernel is converted to HarmonyOS to obtain a kernel image file. Based on the kernel compilation parameters and the target compilation tools, the adaptation layer code and the target code of the open-source HarmonyOS system are compiled to obtain the target image file.

[0008] Start the open-source HarmonyOS system on the target board based on the kernel image file and the target image file.

[0009] According to another aspect of the present invention, an apparatus for porting the open-source HarmonyOS system to the Linux kernel is provided, comprising:

[0010] The adapter layer code acquisition module is used to acquire the adapter layer code built based on the kernel features of the open-source HarmonyOS system framework;

[0011] The compilation module is used to perform kernel code HarmonyOS-ization on the Linux kernel of the target board to obtain a kernel image file. Based on the kernel compilation associated parameters and the target compilation tools, it compiles the adaptation layer code and the target code of the open source HarmonyOS system to obtain the target image file.

[0012] The system startup module is used to start the open-source HarmonyOS system on the target board based on the kernel image file and the target image file.

[0013] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0014] At least one processor; and

[0015] A memory communicatively connected to the at least one processor; wherein,

[0016] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to execute the method for porting the Linux kernel to the open-source HarmonyOS system according to any embodiment of the present invention.

[0017] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions, the computer instructions being configured to cause a processor to execute and implement the method for porting the Linux kernel to the open-source HarmonyOS system as described in any embodiment of the present invention.

[0018] The technical solution of this invention obtains adaptation layer code built based on the kernel features of the open-source HarmonyOS system framework, thereby performing HarmonyOS-ization on the Linux kernel of the target board to obtain a kernel image file. Based on kernel compilation parameters and the target compilation tool, the adaptation layer code and the target code of the open-source HarmonyOS system are compiled to obtain a target image file. Finally, the open-source HarmonyOS system on the target board is started based on the kernel image file and the target image file. This solution allows direct reuse of Linux kernels with adapted drivers from the board manufacturer's Linux and Android systems. The target compilation tool completes OpenHarmony support and kernel image compilation for the Linux kernel with a single click, eliminating the need for hardware driver debugging. This lowers the technical threshold and economic cost of adapting to OpenHarmony, increases the enthusiasm of board manufacturers, paves the way for the promotion of OpenHarmony in various industries, and solves the problems of long development time and high maintenance costs for board manufacturers adapting to OpenHarmony systems. It enables simultaneous support for Linux, Android, and OpenHarmony systems with a single kernel codebase, significantly reducing labor costs and shortening the development cycle.

[0019] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating a method for porting the Linux kernel to the open-source HarmonyOS system, as provided in Embodiment 1 of the present invention.

[0022] Figure 2 This is a flowchart illustrating a method for porting the Linux kernel to the open-source HarmonyOS system, as provided in Embodiment 2 of the present invention.

[0023] Figure 3 This is a schematic diagram of the original system architecture of OpenHarmony provided in Embodiment 2 of the present invention;

[0024] Figure 4 This is a schematic diagram of a decoupled open-source HarmonyOS system framework provided in Embodiment 2 of the present invention;

[0025] Figure 5 This is a schematic diagram of a device for porting the Linux kernel to the open-source HarmonyOS system, provided in Embodiment 3 of the present invention.

[0026] Figure 6 A schematic diagram of an electronic device that can be used to implement embodiments of the present invention is shown. Detailed Implementation

[0027] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0028] It should be noted that the terms "target," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0029] Example 1

[0030] Figure 1 This is a flowchart illustrating a method for porting the open-source HarmonyOS system to a Linux kernel, as provided in Embodiment 1 of the present invention. This embodiment is applicable to the promotion and popularization of the open-source HarmonyOS system. This method can be executed by a device for porting the open-source HarmonyOS system to a Linux kernel. This device can be implemented in hardware and / or software, and can be configured in an electronic device. Figure 1 As shown, the method includes:

[0031] Step 110: Obtain the adaptation layer code built based on the kernel features of the open-source HarmonyOS system framework.

[0032] The adaptation layer code can be a script pre-configured by the user based on the kernel features of the open-source HarmonyOS system, used to generate an image file corresponding to those kernel features. Kernel features can be characteristics of the HarmonyOS kernel that distinguish it from kernels in other systems (Linux and Android). Specifically, kernel features can be manifested as functional components unique to the HarmonyOS kernel.

[0033] In this embodiment of the invention, users can abstract a custom adaptation layer between the open-source HarmonyOS system and the kernel based on the kernel features of the open-source HarmonyOS system framework. The developers can pre-configure the adaptation layer code for this layer and provide it to board manufacturers so that the board manufacturers can quickly port the open-source HarmonyOS system to their Linux kernel.

[0034] Step 120: Perform HarmonyOS kernel code conversion on the target board's Linux kernel to obtain a kernel image file. Based on the kernel compilation parameters and the target compilation tools, compile the adaptation layer code and the open-source HarmonyOS target code to obtain the target image file.

[0035] The target board can be the board whose kernel needs to be adapted for the open-source HarmonyOS system. Kernel compilation parameters can be the parameters required for kernel compilation. The target compilation tool can be a pre-configured compilation tool within the kernel-devel environment. The open-source HarmonyOS target code can be the optimized system code used to generate the open-source HarmonyOS image file. The target image file can be an image file obtained by compiling the adaptation layer code and the open-source HarmonyOS target code.

[0036] In this embodiment of the invention, after the Linux kernel of the target board is initialized, the kernel code is converted to HarmonyOS to generate a kernel image file. That is, the kernel code is converted into the file format of the open source HarmonyOS system. Then, the kernel compilation associated parameters are used to configure the parameters of the compilation environment. The target compilation tool is used to compile the adaptation layer code and the target code of the open source HarmonyOS system in the compilation environment to obtain the target image file.

[0037] For example, the image file compiled from the adaptation layer code can be released along with the image file compiled from the target code of the open-source HarmonyOS. OpenHarmony will no longer require the kernel itself to support open-source HarmonyOS, and the open-source HarmonyOS will have wider support for different Linux versions.

[0038] Step 130: Start the open-source HarmonyOS system on the target board based on the kernel image file and the target image file.

[0039] In this embodiment of the invention, the kernel image file and the target image file can be burned to the target board, and the open-source HarmonyOS system of the target board can be started.

[0040] The technical solution of this invention obtains adaptation layer code built based on the kernel features of the open-source HarmonyOS system framework, thereby performing HarmonyOS-ization on the Linux kernel of the target board to obtain a kernel image file. Based on kernel compilation parameters and the target compilation tool, the adaptation layer code and the target code of the open-source HarmonyOS system are compiled to obtain a target image file. Finally, the open-source HarmonyOS system on the target board is started based on the kernel image file and the target image file. This solution allows direct reuse of Linux kernels with adapted drivers from the board manufacturer's Linux and Android systems. The target compilation tool completes OpenHarmony support and kernel image compilation for the Linux kernel with a single click, eliminating the need for hardware driver debugging. This lowers the technical threshold and economic cost of adapting to OpenHarmony, increases the enthusiasm of board manufacturers, paves the way for the promotion of OpenHarmony in various industries, and solves the problems of long development time and high maintenance costs for board manufacturers adapting to OpenHarmony systems. It enables simultaneous support for Linux, Android, and OpenHarmony systems with a single kernel codebase, significantly reducing labor costs and shortening the development cycle.

[0041] Example 2

[0042] Figure 2 This is a flowchart illustrating a method for porting the Linux kernel to the open-source HarmonyOS system, as provided in Embodiment 2 of the present invention. This embodiment is a specific modification of the above embodiment, providing specific optional implementation methods for obtaining the adaptation layer code built based on the kernel features of the open-source HarmonyOS system framework. For example... Figure 2 As shown, the method includes:

[0043] Step 210: Determine the abstract adaptation layer in the open-source HarmonyOS system framework.

[0044] The abstract adaptation layer can be a hierarchical structure abstracted between the open-source HarmonyOS system and the kernel.

[0045] In this embodiment of the invention, in order to separate the OpenHarmony support function from the kernel and load it dynamically during the OpenHarmony startup process instead of loading it in the kernel, the function can be separated based on the kernel characteristics of the OpenHarmony system framework. That is, the functional components unique to the open-source Harmony system kernel are identified and abstracted into the abstract adaptation layer in the open-source Harmony system framework.

[0046] Step 220: Obtain the adapter layer code associated with the kernel features in the abstract adapter layer.

[0047] In this embodiment of the invention, the kernel-related adaptation layer code written by developers based on the abstract adaptation layer can be obtained.

[0048] Step 230: Perform HarmonyOS kernel code conversion on the target board's Linux kernel to obtain a kernel image file. Based on the kernel compilation parameters and the target compilation tools, compile the adaptation layer code and the open-source HarmonyOS target code to obtain the target image file.

[0049] In an optional embodiment of the present invention, before compiling the adaptation layer code and the target code of the open-source HarmonyOS system based on kernel compilation association parameters and target compilation tools to obtain the target image file, the method may further include: obtaining kernel compilation association parameters that are compatible with the Linux kernel compilation of the target board; and constructing a target compilation tool that is compatible with the Linux kernel compilation environment based on the kernel compilation association parameters.

[0050] Specifically, since different platforms and manufacturers use different customized parameters when compiling the kernel, it is necessary to formulate kernel compilation association parameters that are compatible with the Linux kernel compilation of the target board. Then, based on the kernel compilation association parameters, the compilation environment required for kernel compilation is determined, and a target compilation tool that is compatible with the Linux kernel compilation environment is built according to the determined compilation environment.

[0051] In an optional embodiment of the present invention, kernel compilation associated parameters may include kernel image size, instruction framework, Linux device tree associated directory, image file package name, image output directory, and kernel compilation options.

[0052] The kernel image size can be the kernel image size itself. For example, the instruction set can include, but is not limited to, arm64. The Linux device tree association directory can be a directory associated with the Linux device tree. The Linux device tree association directory can include the Linux device tree entry directory and the Linux device tree file directory. The image file package name is the name of the kernel image package file. The image output directory can be used to represent the export directory of the image file. Kernel compilation options can be used to allow the kernel to automatically load certain modules.

[0053] Optional kernel compilation parameters may also include image block size, defconfig (load default parameters) filename, debug UART (Universal Asynchronous Receiver / Transmitter) port register address, and whether to include a ramdisk (virtual memory disk) in the kernel.

[0054] Step 240: Start the open-source HarmonyOS system on the target board based on the kernel image file and the target image file.

[0055] In an optional embodiment of the present invention, while starting the open-source HarmonyOS system of the target board according to the kernel image file and the target image file, it may also include: loading the kernel dynamic module of the abstract adaptation layer, calling the exported kernel symbol table when the kernel dynamic module is loaded, and calling the reverse registration target interface of the abstract adaptation layer to register functions.

[0056] Here, the kernel dynamic module can be a kernel module in the abstraction adaptation layer, specifically the ko (kernel object) component in the abstraction adaptation layer. The kernel symbol table can be the defined symbols required for loading the kernel dynamic module during operating system startup, and can be exported by the abstraction adaptation layer. The reverse registration target interface can be the interface for calling back the corresponding function of the kernel dynamic module.

[0057] Specifically, while booting the open-source HarmonyOS system on the target board based on the kernel image file and the target image file, the kernel dynamic module of the abstract adaptation layer can be dynamically loaded. When the kernel dynamic module is loaded, the exported kernel symbol table is called to solve the problem of undefined symbols when loading the kernel dynamic module during the boot process of the open-source HarmonyOS system. It can also call the reverse registration target interface of the abstract adaptation layer to register its own functions so that the Linux kernel can call the kernel dynamic module through the reverse registration target interface.

[0058] In an optional embodiment of the present invention, before calling the reverse registration target interface of the abstract adaptation layer to register the function, the method may further include: determining the kernel dynamic module associated with the kernel feature; and creating a reverse registration target interface that matches the kernel feature based on the kernel dynamic module.

[0059] In this embodiment of the invention, based on the kernel characteristics of the open-source HarmonyOS system, the functions corresponding to the kernel characteristics of the open-source HarmonyOS system can be determined. Then, the components corresponding to the functions determined above, namely kernel dynamic modules, can be screened in the kernel of the open-source HarmonyOS system. Furthermore, the abstract adaptation layer provides the reverse registration interface of the kernel dynamic modules, that is, the reverse registration target interface matching the kernel characteristics is obtained.

[0060] In an optional embodiment of the present invention, the kernel dynamic module may include necessary dynamic loading components and non-necessary dynamic loading components; wherein, the necessary dynamic loading components may include system inter-process communication components and permission token management components; the non-necessary dynamic loading components may include at least one of an exception log collection component, a log buffer management component, a crash log capture component, a HarmonyOS log ring buffer component, an event log buffer management component, a user space process watchdog component, an open source file system for distributed storage and processing, and a shared file system.

[0061] Among these components, necessary dynamically loaded components can be critical components that need to be decoupled from the kernel. Non-essential dynamically loaded components can be components that are selectively decoupled from the kernel. The inter-process communication component can be the binder module in the kernel of the open-source HarmonyOS system framework. The permission token management component can be the accesstokenid module in the kernel of the open-source HarmonyOS system framework, responsible for managing permission tokens for HarmonyOS process execution and file access. The exception log collection component can be the blackbox module in the kernel of the open-source HarmonyOS system framework, responsible for callbacks to registered functions when exceptions occur, saving logs, and restarting. The log buffer management component can be the hievent module in the kernel of the open-source HarmonyOS system framework, responsible for event log cache management, and depends on hisysevent. The crash log capture component can be the zerohung module in the kernel of the open-source HarmonyOS system framework, responsible for capturing crash logs. The HarmonyOS log ring buffer component can be the hilog module in the kernel of the open-source HarmonyOS system framework, i.e., the HarmonyOS log ring buffer. The event log buffer management component can be the hisysevent module in the kernel of the open-source HarmonyOS system framework, responsible for event log buffer management. The user-space process watchdog component can be the `watchdog` module, or Hungtask module, within the kernel of the open-source HarmonyOS system framework. The open-source file system for distributed storage and processing is the `hmdfs` file system within the kernel of the open-source HarmonyOS system framework. The shared file system can be the `sharefs` file system within the kernel of the open-source HarmonyOS system framework.

[0062] Optional, non-essential dynamically loaded components may also include the ramoops module and / or the pstore module. The ramoops module is used to dump logs to a non-power-loss memory module after reboot. The pstore module is used to capture kernel crash logs.

[0063] For example, some of the reverse registration interfaces in the reverse registration target interfaces that match kernel features are shown below:

[0064] int register_blackbox_api(struct blackbox_api*bboxapi);

[0065] void unregister_blackbox_api(void).

[0066] int register_hungtask_api(struct hungtask_api*htapi);

[0067] void unregister_hungtask_api(void).

[0068] int register_zerohung_api(struct zerohung_api*zhapi);

[0069] void unregister_zerohung_api(void).

[0070] int register_pstore_api(struct pstore_api*papi);

[0071] void unregister_pstore_api(void).

[0072] The Linux kernel and system architecture of the OpenHarmony community are as follows: Figure 3 As shown, the Linux kernel supports OpenHarmony's dynamic kernel modules, including the binder module, hisysevent module, hungtask module, hievent module, accesstokenid module, hilog module, zerohung module, sharedfs module, hmdfs module, blackbox module, ramoops module, and pstore module. These modules intrude into the core functional logic of the Linux kernel, such as scheduling and file systems. This separates the kernel features supporting OpenHarmony from the OpenHarmony community kernel, extracting these dynamic kernel modules as independent components. Instead of being statically compiled into the kernel, they are compiled separately as dynamically loadable modules and packaged into the open-source HarmonyOS system image file. During system startup, they are dynamically loaded, achieving the goal of separating OpenHarmony-related features from the kernel, reducing the coupling between OpenHarmony and the kernel. The decoupled open-source HarmonyOS system framework can be found in [link to HarmonyOS system image]. Figure 4 .

[0073] In this solution, kernel features that support OpenHarmony are extracted from the OpenHarmony community kernel, compiled, and packaged into the image file corresponding to the adaptation layer code (referred to as the adaptation layer image file). This image file is then released along with the image file corresponding to the open-source HarmonyOS target code (referred to as the open-source HarmonyOS image file). OpenHarmony will no longer require the kernel itself to support OpenHarmony features, and OpenHarmony will have broader support for different Linux versions.

[0074] The kernel-devel-based target compilation tool is used to port the original Android and Linux kernels to OpenHarmony. These kernels, which have already been adapted to board peripheral drivers, will not need to debug drivers, thereby reducing the manpower required for OpenHarmony's southbound adaptation.

[0075] The OpenHarmony system vendor provides board manufacturers with an OpenHarmony system image containing an adaptation layer, along with target compilation tools. Board manufacturers obtain the target compilation tools, convert their board's kernel code to HarmonyOS, and then use these tools to compile the open-source HarmonyOS-compatible image with a single click. The compiled image file is then flashed to the system, booting the open-source HarmonyOS. Board manufacturers do not need to perform driver adaptation on the OpenHarmony community's kernel version; instead, they can directly compile a kernel version that has already been driver-adapted for Linux or Android, and use it with the OpenHarmony system image to boot OpenHarmony.

[0076] Kernel features decoupled from the original kernel are compiled into kernel dynamic modules. After kernel initialization is complete, the OpenHarmony file system is switched, and the kernel dynamic modules that support OpenHarmony are loaded during the startup init process. This reduces the coupling between OpenHarmony and the kernel, making it easier for OpenHarmony to support different kernel versions.

[0077] This solution reduces the coupling between OpenHarmony and the kernel by separating the OpenHarmony-supporting logic from the kernel. The separated kernel functionality is dynamically loaded during OpenHarmony startup, eliminating the need for kernel loading. Furthermore, by using target compilation tools, it enables rapid adaptation of different kernel versions from various manufacturers to OpenHarmony. This means reusing Linux kernels adapted for Linux and Android systems by different board manufacturers to adapt to the OpenHarmony system, reducing the debugging process for drivers on different Linux versions. Board manufacturers only need to maintain one kernel code version that supports Linux, Android, and OpenHarmony systems. This reduces labor costs and shortens the development cycle (reducing the OpenHarmony adaptation work from weeks to months to hours to days), promoting the popularization and promotion of OpenHarmony and playing a crucial role in the formation of the OpenHarmony ecosystem.

[0078] The technical solution of this invention determines the abstract adaptation layer in the open-source HarmonyOS system framework, compiles and packages the kernel features in the abstract adaptation layer to generate adaptation layer code that supports HarmonyOS, then performs HarmonyOS-ization on the Linux kernel of the target board to obtain a kernel image file, and compiles the adaptation layer code and the target code of the open-source HarmonyOS system based on kernel compilation association parameters and target compilation tools to obtain a target image file, and further starts the open-source HarmonyOS system on the target board based on the kernel image file and the target image file. This solution allows direct reuse of Linux kernels with adapted drivers from board manufacturers for Linux and Android systems. OpenHarmony support for the Linux kernel and kernel image compilation can be completed with a single click using the target compilation tool, eliminating the need for hardware driver debugging. This lowers the technical barrier and economic cost of adapting to OpenHarmony, increases the enthusiasm of board manufacturers, paves the way for the promotion of OpenHarmony across various industries, and solves the problems of long development time and high maintenance costs for board manufacturers adapting to OpenHarmony systems. It enables simultaneous support for Linux, Android, and OpenHarmony systems with a single kernel codebase, significantly reducing labor costs and shortening the development cycle.

[0079] Example 3

[0080] Figure 5 This is a schematic diagram of a device for porting the Linux kernel to the open-source HarmonyOS system, as provided in Embodiment 3 of the present invention. Figure 5 As shown, the device includes:

[0081] The adapter layer code acquisition module 310 is used to acquire the adapter layer code built based on the kernel features of the open-source HarmonyOS system framework;

[0082] The compilation module 320 is used to perform kernel code HarmonyOS conversion on the Linux kernel of the target board to obtain a kernel image file, and compile the adaptation layer code and the target code of the open source HarmonyOS system based on the kernel compilation associated parameters and the target compilation tools to obtain a target image file;

[0083] The system startup module 330 is used to start the open-source HarmonyOS system on the target board based on the kernel image file and the target image file.

[0084] The technical solution of this invention obtains adaptation layer code built based on the kernel features of the open-source HarmonyOS system framework, thereby performing HarmonyOS-ization on the Linux kernel of the target board to obtain a kernel image file. Based on kernel compilation parameters and the target compilation tool, the adaptation layer code and the target code of the open-source HarmonyOS system are compiled to obtain a target image file. Finally, the open-source HarmonyOS system on the target board is started based on the kernel image file and the target image file. This solution allows direct reuse of Linux kernels with adapted drivers from the board manufacturer's Linux and Android systems. The target compilation tool completes OpenHarmony support and kernel image compilation for the Linux kernel with a single click, eliminating the need for hardware driver debugging. This lowers the technical threshold and economic cost of adapting to OpenHarmony, increases the enthusiasm of board manufacturers, paves the way for the promotion of OpenHarmony in various industries, and solves the problems of long development time and high maintenance costs for board manufacturers adapting to OpenHarmony systems. It enables simultaneous support for Linux, Android, and OpenHarmony systems with a single kernel codebase, significantly reducing labor costs and shortening the development cycle.

[0085] Optionally, the adaptation layer code acquisition module 310 is specifically used to determine the abstract adaptation layer in the open-source HarmonyOS system framework; compile and package the kernel features in the abstract adaptation layer to generate adaptation layer code that supports HarmonyOS.

[0086] Optionally, the device for porting the Linux kernel to the open-source HarmonyOS system also includes a boot loading and interface acquisition module, which is used to load the kernel dynamic module of the abstract adaptation layer, call the exported kernel symbol table when the kernel dynamic module is loaded, and call the reverse registration target interface of the abstract adaptation layer to register functions.

[0087] Optionally, the apparatus for porting the open-source HarmonyOS system to the Linux kernel further includes obtaining kernel compilation association parameters that are compatible with the Linux kernel compilation of the target board; and constructing a target compilation tool that is compatible with the Linux kernel compilation environment based on the kernel compilation association parameters.

[0088] Optionally, the apparatus for porting the Linux kernel to the open-source HarmonyOS system further includes a reverse registration target interface creation module, used to determine the kernel dynamic module associated with the kernel feature; and based on the kernel dynamic module, to create a reverse registration target interface that matches the kernel feature.

[0089] Optional kernel compilation parameters include kernel image size, instruction set, Linux device tree associated directory, image file package name, image output directory, and kernel compilation options.

[0090] Optionally, the kernel dynamic module includes necessary dynamically loaded components and non-necessary dynamically loaded components; wherein, the necessary dynamically loaded components include system inter-process communication components and permission token management components; the non-necessary dynamically loaded components include at least one of the following: exception log collection component, log buffer management component, crash log capture component, HarmonyOS log ring buffer component, event log buffer management component, user space process watchdog component, open source file system for distributed storage and processing, and shared file system.

[0091] The apparatus for porting the Linux kernel to the open-source HarmonyOS system provided in the embodiments of the present invention can execute the method for porting the Linux kernel to the open-source HarmonyOS system provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of executing the method.

[0092] Example 4

[0093] Figure 6 A schematic diagram of an electronic device that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0094] like Figure 6 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0095] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0096] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the method of porting the Linux kernel to the open-source HarmonyOS system.

[0097] In some embodiments, the method for porting the Linux kernel to the open-source HarmonyOS system can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the method for porting the Linux kernel to the open-source HarmonyOS system described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to perform the method for porting the Linux kernel to the open-source HarmonyOS system by any other suitable means (e.g., by means of firmware).

[0098] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0099] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0100] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0101] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0102] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0103] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS servers, such as high management difficulty and weak business scalability.

[0104] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0105] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for porting the open-source HarmonyOS system to the Linux kernel, characterized in that, include: Obtain the adaptation layer code built based on the kernel features of the open-source HarmonyOS system framework; The kernel code of the Linux kernel on the target board is converted to HarmonyOS to obtain a kernel image file. Based on the kernel compilation parameters and the target compilation tools, the adaptation layer code and the target code of the open source HarmonyOS system are compiled to obtain a target image file. Based on the kernel image file and the target image file, start the open-source HarmonyOS system on the target board; The acquisition of the adaptation layer code built based on the kernel features of the open-source HarmonyOS system framework includes: The abstract adaptation layer in the open-source HarmonyOS system framework is defined; the abstract adaptation layer is a hierarchical structure abstracted between the open-source HarmonyOS system and the kernel. Obtain the adapter layer code associated with the kernel features in the abstract adapter layer; Before compiling the adaptation layer code and the open-source HarmonyOS target code based on kernel compilation association parameters and target compilation tools to obtain the target image file, the process further includes: Obtain the kernel compilation associated parameters that are compatible with the Linux kernel compilation of the target board; Based on the kernel compilation associated parameters, construct a target compilation tool adapted to the Linux kernel compilation environment.

2. The method according to claim 1, characterized in that, The process of starting the open-source HarmonyOS system on the target board based on the kernel image file and the target image file also includes: Load the kernel dynamic module of the abstract adaptation layer. When the kernel dynamic module is loaded, call the exported kernel symbol table and call the reverse registration target interface of the abstract adaptation layer to register functions.

3. The method according to claim 2, characterized in that, Before calling the reverse registration target interface of the abstract adaptation layer to register functions, the following is also included: Identify the kernel dynamic modules associated with the aforementioned kernel features; Based on the kernel dynamic module, a reverse registration target interface matching the kernel characteristics is created.

4. The method according to claim 1, characterized in that, The kernel compilation associated parameters include kernel image size, instruction framework, Linux device tree associated directory, image file package name, image output directory, and kernel compilation options.

5. The method according to claim 3, characterized in that, The kernel dynamic module includes necessary dynamic loading components and non-necessary dynamic loading components; wherein, the necessary dynamic loading components include system inter-process communication components and permission token management components; the non-necessary dynamic loading components include at least one of the following: exception log collection component, log buffer management component, crash log capture component, HarmonyOS log ring buffer component, event log buffer management component, user space process watchdog component, open source file system for distributed storage and processing, and shared file system.

6. A device for porting the open-source HarmonyOS system to the Linux kernel, characterized in that, include: The adapter layer code acquisition module is used to acquire the adapter layer code built based on the kernel features of the open-source HarmonyOS system framework; The compilation module is used to perform kernel code HarmonyOS-ization on the Linux kernel of the target board to obtain a kernel image file, and to compile the adaptation layer code and the open-source HarmonyOS target code based on kernel compilation association parameters and target compilation tools to obtain a target image file; The system startup module is used to start the open-source HarmonyOS system on the target board based on the kernel image file and the target image file; Specifically, the adaptation layer code acquisition module is used to determine the abstract adaptation layer in the open-source HarmonyOS framework; the abstract adaptation layer is a hierarchical structure abstracted between the open-source HarmonyOS system and the kernel; the kernel features in the abstract adaptation layer are compiled and packaged to generate adaptation layer code that supports HarmonyOS. The device further includes: acquiring kernel compilation association parameters adapted to the Linux kernel compilation of the target board; and constructing a target compilation tool adapted to the Linux kernel compilation environment based on the kernel compilation association parameters.

7. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the method of porting the Linux kernel to the open-source HarmonyOS system as claimed in any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that are used to cause a processor to execute the method of porting the Linux kernel to the open-source HarmonyOS system as described in any one of claims 1-5.

Images