Open source gap read-only file system integration and debugging method based on EROFS

Abstract

The invention relates to the technical field of integration and debugging, and discloses an open source gap read-only file system integration and debugging method based on an EROFS. Comprising the following steps: transplanting a tool set of the EROFS into an open-source gap system to obtain a transplanted open-source gap system; an EROFS kernel is configured in the transplanted open source swan system, starting parameters are adjusted, an EROFS partition mirror image configuration file and an optimization compiling command are configured, and the open source swan system supporting the EROFS is obtained; and compiling, packaging and burning the open source gap system supporting the EROFS to obtain the open source gap system integrated with the EROFS. According to the method, deep integration of the EROFS in an open source gap system kernel is realized, a read-only file system architecture supporting each partition of the EROFS is obtained, the storage efficiency and the random reading performance can be remarkably improved, and the safety and the consistency of the file system are ensured.

Description

Technical Field

[0001] The present invention relates to the technical field of system integration and debugging, and in particular to an open source Hongmeng read-only file system integration and debugging method based on EROFS and an open source Hongmeng read-only file system integration and debugging device based on EROFS. Background Art

[0002] Currently, the open-source Hongmeng system primarily uses the Ext4 (Fourth Extended File System) file system. Ext4 offers strong compatibility, stable operation on Hongmeng devices, and supports dynamic read and write, making it suitable for scenarios with frequent data changes. Ext4 also boasts a comprehensive tool set that supports file system creation, inspection, and repair.

[0003] However, in read-only storage scenarios, Ext4 has certain limitations. For example, its use of block index management can easily lead to fragmentation when storing small files, resulting in wasted storage space. Furthermore, even when the partition is in read-only mode, the additional log and metadata storage still incurs a certain amount of storage overhead. Furthermore, when mounted as read-only, Ext4 still requires inode and metadata management, which affects file read speeds. During random reads, performance is low due to the lack of read-only optimized data structures. Furthermore, Ext4 lacks built-in transparent compression capabilities and must rely on external tools for compression processing, resulting in low storage efficiency. Summary of the invention

[0004] The purpose of the present invention is to overcome the problems of poor storage performance and low storage efficiency in the read-only storage scenario of the file system integrated with the open source Harmony system in the prior art, and to provide an open source Harmony read-only file system integration and debugging method based on EROFS.

[0005] To achieve the above objectives, the present invention provides an open source Hongmeng read-only file system integration and debugging based on EROFS, which mainly includes:

[0006] Port the EROFS tool set to the open source Hongmeng system to obtain the ported open source Hongmeng system;

[0007] Configuring the EROFS kernel in the transplanted open source Hongmeng system, adjusting startup parameters, configuring the EROFS partition image configuration file and optimizing compilation commands to obtain an open source Hongmeng system that supports EROFS;

[0008] Compile, package and burn the open source Hongmeng system that supports EROFS to obtain the open source Hongmeng system with integrated EROFS.

[0009] Optionally, the process of configuring the EROFS kernel includes:

[0010] Enable the EROFS configuration item in the kernel configuration file corresponding to the HarmonyOS-enabled device.

[0011] Optionally, the process of adjusting the startup parameters includes:

[0012] Adjust the startup parameters of the HarmonyOS-enabled device to obtain adjusted startup parameters, where the adjusted startup parameters are used to mount the EROFS read-only file system;

[0013] Adjust the file system mount adaptation file in the startup subsystem of the transplanted OpenHarmony system to obtain an adjusted startup subsystem, where the adjusted startup subsystem is used to identify the EROFS read-only file system type during startup.

[0014] Optionally, the process of configuring the EROFS partition image configuration file and optimizing the compilation command includes:

[0015] Add the EROFS partition image configuration file and the EROFS image production script to the build subsystem of the transplanted OpenHarmony system;

[0016] Add the EROFS compilation item to the transplanted OpenHarmony system and adapt the corresponding build configuration file to obtain a configured build subsystem.

[0017] Optionally, after obtaining the OpenHarmony system integrated with EROFS, it further includes debugging the OpenHarmony system integrated with EROFS. The debugging process specifically includes:

[0018] Add the EROFS mount item of the HDC debugging command, where the EROFS mount item is used to support remounting and unmounting;

[0019] Perform mount debugging on the OpenHarmony system integrated with EROFS based on the EROFS mount item to obtain a debugged OpenHarmony system integrated with EROFS.

[0020] Optionally, the performing mount debugging on the OpenHarmony system integrated with EROFS based on the EROFS mount item to obtain a debugged OpenHarmony system integrated with EROFS includes:

[0021] Add the overlay environment parameter to the OpenHarmony system integrated with EROFS, where the overlay environment parameter is used to determine whether the file system uses the overlay mount type;

[0022] Adjust the mount partition table of the open-source HarmonyOS integrated with EROFS to obtain an adjusted mount partition table, which is used to adjust the mount type of the EROFS partition to the overlay mount type;

[0023] Add an overlay directory creation task to the initialization configuration file, which is used to determine whether to perform a mount operation;

[0024] Use the server and the development end installed with the open-source HarmonyOS integrated with EROFS for mount debugging, and add an operation task corresponding to the EROFS mount item to the HDC debugging command of the server, and add an operation task corresponding to the EROFS mount item to the HDC debugging command of the development end.

[0025] Optionally, the process of using the server and the development end installed with the open-source HarmonyOS integrated with EROFS for mount debugging includes:

[0026] If it is determined to perform a remount operation and the value of the overlay environment parameter is the same as the preset successful mount value, prompt the user that the overlay is successfully mounted; if it is determined to perform a remount operation and the value of the overlay environment parameter is different from the preset successful mount value, set the value of the overlay environment parameter to be the same as the preset successful mount value, and create an EROFS partition directory; if it is determined to perform an umount operation, clear the value of the overlay environment parameter and delete the EROFS partition directory;

[0027] Restart the server and the development end, add an overlay directory creation task to the initialization configuration file and execute the mount file system operation. If the value of the overlay environment parameter is the same as the preset successful mount value, remount the EROFS partition as the overlay mount type; if the value of the overlay environment parameter is different from the preset successful mount value, mount each partition according to the original fstab configuration.

[0028] The second aspect of the present invention provides an open-source HarmonyOS read-only file system integration and debugging device based on EROFS, which mainly includes:

[0029] A transplantation module, which is used to transplant the tool set of EROFS into the open-source HarmonyOS to obtain a transplanted open-source HarmonyOS;

[0030] An adaptation module, which is used to configure the EROFS kernel in the transplanted open-source HarmonyOS, adjust the startup parameters, configure the EROFS partition image configuration file and optimize the compilation command to obtain an open-source HarmonyOS that supports EROFS;

[0031] An integration module is used to compile, package, and burn an open-source HarmonyOS that supports EROFS to obtain an open-source HarmonyOS integrated with EROFS.

[0032] The third aspect of the present invention provides an electronic device, which includes a memory for storing executable commands; and a processor for calling and running the executable commands in the memory to execute the steps of the above-mentioned method for integrating and debugging the read-only file system of the open-source HarmonyOS based on EROFS.

[0033] The fourth aspect of the present invention provides a computer-readable storage medium, in which program commands are stored. When the program commands are run by a processor, the steps of the above-mentioned method for integrating and debugging the read-only file system of the open-source HarmonyOS based on EROFS are implemented.

[0034] Compared with the prior art, the beneficial effects of this solution are as follows:

[0035] In the present invention, the toolset of EROFS is transplanted into the open-source HarmonyOS, and the source code of the open-source HarmonyOS is kernel-adapted, startup parameter adjusted, EROFS partition image format file configured, and compilation commands optimized, so as to deeply integrate EROFS into the open-source HarmonyOS kernel, obtain a read-only file system architecture that supports each partition of EROFS, and can achieve higher storage efficiency and random read performance than the Ext4 file system, and ensure the security and consistency of the file system.

[0036] Other features and advantages of the embodiments of the present invention will be described in detail in the subsequent specific implementation part. Description of the Drawings

[0037] The drawings are used to provide a further understanding of the embodiments of the present invention, and constitute a part of the specification. Together with the following specific implementation, they are used to explain the embodiments of the present invention, but do not constitute a limitation to the embodiments of the present invention. In the drawings:

[0038] Figure 1 It is a comparison chart of FIO micro-benchmark test results for different CPU frequency reading modes;

[0039] Figure 2 It is a flowchart of the method for integrating and debugging the read-only file system of the open-source HarmonyOS based on EROFS of the present invention;

[0040] Figure 3 It is a schematic diagram of the read-only file system architecture of the open-source HarmonyOS based on EROFS of the present invention;

[0041] Figure 4 It is a flowchart of Erofs debugging based on the HDC command of the present invention;

[0042] Figure 5 Schematic diagram of the module of the open-source HarmonyOS read-only file system integration and debugging device based on EROFS of the present invention;

[0043] Figure 6 Schematic diagram of the structure of the electronic device of the present invention. Specific implementation manners

[0044] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0045] Many specific details are set forth in the following description in order to fully understand the present invention. However, the present invention may also be implemented in other ways different from those described herein. Those skilled in the art may make similar extensions without departing from the connotation of the present invention. Therefore, the present invention is not limited by the specific embodiments disclosed below.

[0046] Facing the file system integrated in the existing open-source HarmonyOS system, in the read-only storage scenario, there are problems of poor storage performance and low storage efficiency. Considering that the Enhanced Read-Only FileSystem (EROFS) is a read-only file system natively supported by the Linux kernel and is suitable for optimization in read-only scenarios such as embedded devices, system partitions, and container images. Compared with Ext4, EROFS has significant advantages in the read-only partition of the open-source HarmonyOS system. It adopts metadata indexing and block mapping optimization to achieve zero-fragmentation storage, improve the storage efficiency of small files, and at the same time support compression algorithms such as LZ4 and LZMA, which can effectively improve the storage space utilization rate and reduce the image volume. In addition, EROFS is optimized for storage devices and has better performance in random reading, which can accelerate the loading of applications and system components and improve the system startup speed.

[0047] Figure 1The figure shows the comparison chart of FIO micro-benchmark test results of various file systems in three read modes under different CPU frequencies. The file systems used include: EROFS read-only file system, Btrfs file system with 128K block size using LZO compression, Squashfs read-only file system with 4K block size, Squashfs read-only file system with 8K block size, Squashfs read-only file system with 16K block size, Squashfs read-only file system with 128K block size, Linux standard log file system (Ext4), and Flash-friendly file system (F2FS); the CPU frequencies include: A73-2362MHz, A73-903MHz, A53-1844MHz, and A53-533MHz. Figure 1 The vertical axis represents the throughput (MB / s), which is the data transfer rate of the file system. The higher the value, the better the performance; the horizontal axis shows the stride access mode, random access mode, and sequential access mode corresponding to different CPU cores and frequencies.

[0048] Table 1 shows the FIO micro-benchmark test results of different CPU frequency read modes.

[0049] Table 1

[0050]

[0051] Combined with Figure 1 and Table 1, it can be seen that the throughput of EROFS in sequential access far exceeds that of other file systems, and it still remains leading in random access, while F2FS and Ext4 also have good performances. As the CPU frequency decreases, the throughput of all file systems decreases, but EROFS still has an advantage. In addition, the throughput of sequential access is generally higher than that of random access, indicating that the optimization of the file system should focus more on sequential read and write performance.

[0052] Based on the above analysis, the present invention proposes an open-source HarmonyOS read-only file system integration and debugging method based on EROFS. mainly by transplanting the tool set of EROFS into the open-source HarmonyOS system, and performing kernel adaptation, EROFS partition image format file configuration, and compilation command optimization on the source code of the open-source HarmonyOS system, so that the open-source HarmonyOS system supports the compilation, packaging, and burning of EROFS read-only file system images. At the same time, by optimizing the HDC (Harmonized Device Communication) tool and adding a new EROFS mounting mechanism, according to the designed mounting and debugging process, the mounting and debugging of the open-source HarmonyOS system integrated with EROFS are realized between the server side and the development side, which can effectively enhance the adaptation ability of the device installing the open-source HarmonyOS system to EROFS, effectively improve the storage efficiency, random read performance, and improve the device startup speed and developer debugging experience.

[0053] Please refer to Figure 2 and Figure 3 , an embodiment of the present invention provides an open-source HarmonyOS read-only file system integration and debugging method based on EROFS, including:

[0054] Step 100: Transplant the tool set of EROFS into the open-source HarmonyOS system to obtain the transplanted open-source HarmonyOS system.

[0055] Specifically, transplant the tool set of EROFS into the open-source HarmonyOS system. Specifically, transplant it to the third_party directory under the source code of the open-source HarmonyOS system to support the full life cycle management from image building, compilation to deployment. Among them, the tool set of EROFS includes an image making tool (mkfs.erofs), an integrity check tool (fsck.erofs), a debugging and analysis tool (dump.erofs), etc. The tool set is used to make the Erofs file system image and ensure the integrity of the file system by using the tool set commands in the image, and can realize end-to-end EROFS image processing, which is convenient for supporting image making and debugging.

[0056] Step 200: Configure the EROFS kernel in the transplanted open-source HarmonyOS system, adjust the startup parameters, configure the EROFS partition image configuration file and optimize the compilation command to obtain an open-source HarmonyOS system that supports EROFS.

[0057] Specifically, since the compilation environment of the open-source HarmonyOS system has poor compatibility with the tool set of EROFS, this embodiment solves the compilation compatibility problem by adjusting the tool set source code to adapt to the build system of the open-source HarmonyOS system. Specifically, it includes: in the source code of the transplanted open-source HarmonyOS system, configure the Erofs kernel for the HarmonyOS-enabled device and adjust the startup parameters, configure the image format files of the Erofs partitions (such as system and vendor) of the open-source HarmonyOS system, optimize the compilation commands of the application layer of the open-source HarmonyOS system, use the image making tool (mkfs.erofs) of the Erofs-utils tool set to make images in the script code for compiling the build system, add a compilation module of the EROFS tool set to the build subsystem of the open-source HarmonyOS system, define GN rules (such as ohos_erofs_utils.gni) to ensure that executable files are automatically generated during compilation. And add erofs options to the startup mount source code fstab_mount.c in the source code of the open-source HarmonyOS system to enable EROFS mounting. Among them, the HarmonyOS-enabled device refers to a circuit board or a whole machine device installed with the open-source HarmonyOS system that can implement functions including but not limited to startup and mounting.

[0058] Step 300: Compile, package, and burn the open-source HarmonyOS that supports EROFS to obtain the open-source HarmonyOS integrated with EROFS.

[0059] Specifically, after optimizing the compilation commands of the open-source HarmonyOS, use mkfs.erofs to generate partition images such as system.img and vendor.img, as well as generate a kernel boot image (boot.img) and a vendor boot image (vendor_boot.img) that support EROFS. Then execute the compilation, packaging, and burning commands to obtain the open-source HarmonyOS integrated with EROFS.

[0060] In this embodiment, by transplanting the toolset of EROFS into the open-source HarmonyOS and performing kernel adaptation, startup parameter adjustment, EROFS partition image format file configuration, and compilation command optimization on the source code of the open-source HarmonyOS, EROFS is deeply integrated into the kernel of the open-source HarmonyOS, obtaining a read-only file system architecture that supports each partition of EROFS, which can achieve higher storage efficiency and random read performance than the Ext4 file system, and ensure the security and consistency of the file system to prevent the content from being maliciously adjusted.

[0061] In a preferred embodiment, the process of configuring the EROFS kernel in step 200 includes:

[0062] Step 210: Enable the EROFS configuration item in the kernel configuration file corresponding to the HarmonyOS-enabled device.

[0063] Specifically, provide basic support for the Erofs file system in the kernel compilation configuration file of the transplanted open-source HarmonyOS, and enable the DEFCONFIG configuration in the kernel layer configuration file corresponding to the HarmonyOS-enabled device, that is, configure CONFIG_EROFS_FS = y to enable the kernel to support the Erofs type of file system. Then selectively enable advanced features according to actual needs. For example, enable the compression option (such as CONFIG_EROFS_FS_LZ4) in the kernel compilation configuration file.

[0064] In a preferred embodiment, the process of adjusting the startup parameters in step 200 includes:

[0065] Step 220: Adjust the startup parameters of the HarmonyOS-enabled device to obtain adjusted startup parameters, and the adjusted startup parameters are used to mount the EROFS read-only file system.

[0066] Specifically, since the open-source HarmonyOS is passed to the kernel through the Bootloader (such as U-Boot) or the cmdline of boot.img, and bootargs is the startup parameter string passed to the Linux kernel, which is used to control the kernel initialization behavior (such as root file system mounting, console output, hardware debugging, etc.), therefore, adjusting the startup parameters of the HarmonyOS-enabled device in the Bootloader (such as U-Boot) environment variables or the kernel cmdline of boot.img, for example, adding rootfstype=erofs to specify the root file system type as EROFS; adding compression options (such as erofs_comp=lz4) to enable transparent compression, which helps to improve the storage space utilization rate, reduce the burning time, and enhance the system security; checking whether the kernel startup parameters take effect by cat / proc / cmdline. It can be seen that in this embodiment, by adjusting the startup parameters of the HarmonyOS-enabled device, the EROFS file system can be correctly mounted when the device starts up.

[0067] Step 230: Adjust the file system mount adaptation file in the startup subsystem of the transplanted open-source HarmonyOS to obtain an adjusted startup subsystem, and the adjusted startup subsystem is used to recognize the EROFS read-only file system type when starting up.

[0068] Specifically, implementing mount configuration and startup mounting in the startup subsystem in the system framework layer of the transplanted open-source HarmonyOS specifically includes: modifying the startup parameter bootargs of the DTS configuration module in the kernel layer of the HarmonyOS-enabled device to modify the file system type mounted by the startup parameter into the Erofs read-only file system to implement file system mount adaptation; adding the Erofs type in the fstab_mount.c source code to ensure that the fstab_mount function in the init process source code supports Erofs type parsing, so that the device can recognize the Erofs file system type when starting up. For example, adjusting the fstab mount configuration file to change the file system types of partitions such as system and vendor to erofs, and adding mount options such as LZ4 or LZMA to change the file system types of these partitions from ext4 to erofs. If further, configuring conditional Job in init.cfg to implement dynamic mounting using overlayfs (such as HDC debugging). In this embodiment, by flexibly adjusting the startup subsystem of the open-source HarmonyOS, the system can correctly recognize and mount the EROFS partition during the initialization phase.

[0069] In a preferred implementation manner, the process of configuring the EROFS partition image configuration file and optimizing the compilation command in step 200 includes:

[0070] Step 240: Add an EROFS partition image configuration file and an EROFS image making script to the build subsystem of the transplanted OpenHarmony system;

[0071] Step 250: Add an EROFS compilation item to the transplanted OpenHarmony system and adapt the corresponding build configuration file to obtain a configured build subsystem.

[0072] Specifically, in the build subsystem of the system framework layer of the transplanted OpenHarmony system, build script development, parameter adjustment, image making and image configuration are implemented, specifically including: adding an Erofs partition image making configuration file to the build subsystem, and adding an Erofs image making script mkeroimage.py, which is used to call the Erofs-utils toolset to make an Erofs image through this script during system compilation; adding an EROFS compilation item (i.e., the erofs_enable option) to the transplanted OpenHarmony system, and adapting the corresponding BUILD.gn file, which is used to select whether to compile the Erofs file system during compilation.

[0073] In this embodiment, by inserting an EROFS image generation step into the compilation process and replacing the default Ext4 process, it is ensured that the EROFS image construction can be seamlessly embedded into the OpenHarmony compilation process, which can significantly improve the storage space utilization rate and random read performance, while maintaining system stability.

[0074] In a preferred implementation manner, after obtaining the OpenHarmony system integrated with EROFS in step 300, it further includes the process of debugging the OpenHarmony system integrated with EROFS, specifically including:

[0075] Step 400: Add an EROFS mount item for the HDC debugging command, and the EROFS mount item is used to support remounting and unmounting.

[0076] Specifically, before adding the EROFS mount entry for the HDC debug command, it is necessary to first execute the mount dependency configuration. For example, create a task for the overlay directory in init.cfg and ensure that the overlayfs and erofs drivers are enabled in the kernel. Then, add the EROFS mount entry to the HDC debug command of the open-source HarmonyOS integrated with EROFS to implement the remount (hdcerofs remount) and umount (hdc erofs umount) debug commands for debugging the image of the Erofs file system type. This enables the extended HDC toolset to support the dynamic mounting and unmounting operations of the EROFS partition, facilitating developers to debug the read-only file system. Among them, the remount mechanism is used to trigger the overlayfs mount and allow temporary writes; the umount mechanism is mainly used to unmount the OverlayFS or clean up the temporary mount point for the read-only EROFS file system, release the mounted file system resources, and ensure data consistency and system stability.

[0077] Step 500: Perform mount debugging on the open-source HarmonyOS integrated with EROFS based on the EROFS mount entry to obtain the debugged open-source HarmonyOS integrated with EROFS.

[0078] Specifically, based on the EROFS mount entry, debug the remount and umount debug commands of the open-source HarmonyOS integrated with EROFS to ensure that the open-source HarmonyOS integrated with EROFS can stably implement the dynamic mounting and unmounting functions, thereby obtaining the debugged open-source HarmonyOS integrated with EROFS.

[0079] In a preferred embodiment, step 500 of performing mount debugging on the open-source HarmonyOS integrated with EROFS based on the EROFS mount entry to obtain the debugged open-source HarmonyOS integrated with EROFS includes:

[0080] Step 510: Add overlay environment parameters to the open-source HarmonyOS integrated with EROFS, where the overlay environment parameters are used to determine whether the file system uses the overlay mount type;

[0081] Step 520: Adjust the mount partition table of the open-source HarmonyOS integrated with EROFS to obtain an adjusted mount partition table, where the adjusted mount partition table is used to adjust the mount type of the EROFS partition to the overlay mount type;

[0082] Step 530: Add a task for creating the overlay directory in the initialization configuration file, and the task for creating the overlay directory is used to determine whether to perform a mount operation;

[0083] Step 540: Use the server and development side of the open-source HarmonyOS with the integrated EROFS for mounting and debugging, and add operation tasks corresponding to the EROFS mount entry to the HDC debugging command on the server side and add operation tasks corresponding to the EROFS mount entry to the HDC debugging command on the development side.

[0084] Specifically, by presetting an overlay directory creation task in the initialization (init) process of the open-source HarmonyOS with the integrated EROFS, reading environment parameters, and judging whether to perform hdc erofs remount and hdc erofs umount according to the values of the environment parameters. Among them, the remount and umount of Erofs are implemented based on overlay. The specific process includes: adding overlay environment parameters according to the method of adding environment parameters in the open-source HarmonyOS to judge whether the file system needs to be mounted as overlay, that is, judging whether the file system adopts the overlay mounting type; adding an overlay directory creation task (i.e., conditional jobs) in the initialization configuration file init.cfg to judge whether to perform the mounting operation when the system starts; since the fstab_mount mount is implemented based on the fstab file, the mounting partition table of the file system table fstab is modified to change the mounting types of EROFS partitions such as system, vendor, sys_prod, and chip_prod to the overlay mounting type. Then, the read-only file system of the open-source HarmonyOS with the integrated EROFS can be mounted using hdc erofs remount, and the read-only file system of the open-source HarmonyOS with the integrated EROFS can be unmounted using hdc erofs umount, so as to quickly achieve efficient debugging of the read-only Erofs type system image. It can be seen that in this embodiment, by optimizing the configuration of the environment parameters and the mounting partition table, flexible mounting management of the read-only partition can be achieved, ensuring the security of the system.

[0085] Then, the HDC debugging commands are divided into the server side and the host side. The server side and the host side of the open-source HarmonyOS with the integrated EROFS are used for mounting debugging. Corresponding operation tasks of the EROFS mount item are added to the HDC debugging commands on the server side, and operation tasks corresponding to the EROFS mount item are added to the HDC debugging commands on the host side. The hdc erofs remount or hdc erofs umount command is used for identification and judgment, and the mount operation result is fed back to the server side so that the server side can perform subsequent operations until the dynamic mount and unmount function tests are successful, and the mount debugging task ends. It can be seen that this embodiment supports the synchronization of EROFS operations between the host side and the server side by designing a complete EROFS debugging step, thereby achieving cross-platform debugging.

[0086] In a preferred example, Figure 4 The following shows the process of mounting debugging using the server side and the host side of the open-source HarmonyOS with the integrated EROFS in step 540, including:

[0087] The host device recognizes the hdc erofs command, uses hdcd to receive the hdc command from the host, and sets the remount system property; then, it is judged whether the hdc erofs command is to execute the hdc erofs remount operation or the hdc erofs umount operation. If it is judged to execute the remount operation, the value of the overlay environment parameter persist.overlay.mount.enable is obtained. If it is equal to 1, it means that the overlay has been successfully mounted, and the user is prompted that the overlay has been successfully mounted. Then, the server side and the host side do not need to restart the server side and can continue to perform subsequent operations; if it is not equal to 1, it means that the overlay has not been successfully mounted, the value of persist.overlay.mount.enable is set to 1, and the workdir\upperdir directory of each partition is created in the data directory, and the file system needs to be remounted as an overlay; if it is judged to execute the unmount operation, the value of persist.overlay.mount.enable is set to 0, and the EROFS partition directory is deleted, and the file system needs to be remounted as an overlay. Among them, 1 represents the value of persist.overlay.mount.enable when the preset successful mount occurs, 0 represents clearing the value of persist.overlay.mount.enable, and other values represent that the overlay has not been successfully mounted.

[0088] For the case where the file system needs to be remounted as overlay, restart the server and the development end, execute the job in the initialization configuration file, and execute mount_fstab to mount the EROFS read-only file system. Then, check whether the value of persist.overlay.mount.enable is equal to 1. If it is equal to 1, it means that the overlay has been successfully mounted, and then remount the EROFS partition as overlay according to fstab_overlay, and the client can continue to execute the subsequent operations. If it is not equal to 1, it means that the overlay has not been successfully mounted, that is, the EROFS type mounting is abnormal. In this case, mount each EROFS partition according to the original fstab configuration, the client continues to execute the subsequent operations, and prompts the development end that the EROFS type mounting is abnormal, so as to facilitate subsequent optimization of the EROFS mounting settings and then re-execute the mounting and debugging process. Among them, the overlay environment parameter represents the system attribute parameter used to control the start and stop of the overlay mounting mechanism.

[0089] It can be seen that through the complete EROFS debugging steps in this example, the dynamic management of the EROFS read-only file system can be effectively realized.

[0090] The method of the present invention has realized the function of integrating EROFS in the open-source HarmonyOS based on RK3588. The comparison results of different file systems on the RK3588 device shown in Table 2 show that using the EROFS file system can save 13% of the storage space compared with the Ext4 file system, and the burning time can be increased by more than 27%. At the same time, the EROFS file system can ensure the security and consistency of the file system and prevent the content from being maliciously adjusted.

[0091] Table 2

[0092]

[0093] Please refer to Figure 5 , the present invention provides an open-source HarmonyOS read-only file system integration and debugging device based on EROFS, including:

[0094] A transplantation module 510, which is used to transplant the tool set of EROFS into the open-source HarmonyOS to obtain the transplanted open-source HarmonyOS;

[0095] An adaptation module 520, which is used to configure the EROFS kernel in the transplanted open-source HarmonyOS, adjust the startup parameters, configure the EROFS partition image configuration file and optimize the compilation command to obtain the open-source HarmonyOS that supports EROFS;

[0096] An integrated module 530 is used to compile, package, and burn the open-source HarmonyOS that supports EROFS to obtain the open-source HarmonyOS integrated with EROFS.

[0097] Specifically, in this embodiment, the specific functions of the above-mentioned open-source HarmonyOS read-only file system integration and debugging device based on EROFS can also refer to the corresponding descriptions in the above-mentioned open-source HarmonyOS read-only file system integration and debugging method, which will not be elaborated here.

[0098] Based on the above embodiments, the present invention also provides an electronic device, and its principle block diagram can be as Figure 6 shown. This electronic device can be used to execute the open-source HarmonyOS read-only file system integration and debugging method provided in the above embodiments. For the sake of brevity, it will not be elaborated here. The electronic device includes: a processor, the processor is coupled to a memory, the memory is used to store computer programs or commands, and the processor is used to execute the computer programs or commands stored in the memory, so that the methods in the above method embodiments are executed.

[0099] The present invention also provides a computer-readable storage medium, on which computer commands for implementing the methods in the above method embodiments are stored.

[0100] For example, when the computer program is executed by a computer, the computer can implement the methods in the above method embodiments.

[0101] The embodiments of the present application also provide a computer program product containing commands, and when the commands are executed by a computer, the computer implements the methods in the above method embodiments.

[0102] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or by a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professionals can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0103] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the above-described systems, devices, and units can refer to the corresponding processes in the foregoing method embodiments, which will not be elaborated here.

[0104] In several embodiments provided in the present application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection between each other can be through some interfaces. The indirect coupling or communication connection of the device or unit can be in electrical, mechanical, or other forms.

[0105] The units described as separate components may or may not be physically separated. The components displayed as units may or may not be physical units, that is, they can be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0106] In addition, in each embodiment of the present application, the functional units can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit.

[0107] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art or a part of this technical solution can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: USB flash drives, mobile hard disks, read-only memories (ROMs), random access memories (RAMs), magnetic disks, or optical discs and other various media that can store program codes.

Claims

1. An open-source HarmonyOS read-only file system integration and debugging method based on EROFS, characterized in that, The method includes: Port the toolset of EROFS to the open-source HarmonyOS to obtain the ported open-source HarmonyOS; Configure the EROFS kernel in the ported open-source HarmonyOS, adjust the startup parameters, configure the EROFS partition image configuration file and optimize the compilation command to obtain the open-source HarmonyOS that supports EROFS; Compile, package and burn the open-source HarmonyOS that supports EROFS to obtain the open-source HarmonyOS integrated with EROFS.

2. The method for integrating and debugging the open-source HarmonyOS read-only file system based on EROFS according to claim 1, wherein The process of configuring the EROFS kernel includes: Enable the EROFS configuration item in the kernel configuration file corresponding to the HarmonyOS device.

3. The method for integrating and debugging the open-source HarmonyOS read-only file system based on EROFS according to claim 1, wherein The process of adjusting the startup parameters includes: Adjust the startup parameters of the HarmonyOS device to obtain the adjusted startup parameters, and the adjusted startup parameters are used to mount the EROFS read-only file system; Adjust the file system mount adaptation file in the startup subsystem of the ported open-source HarmonyOS to obtain the adjusted startup subsystem, and the adjusted startup subsystem is used to identify the EROFS read-only file system type at startup.

4. The method for integrating and debugging the open-source HarmonyOS read-only file system based on EROFS according to claim 1, wherein The process of configuring the EROFS partition image configuration file and optimizing the compilation command includes: Add the EROFS partition image configuration file and the EROFS image production script to the build subsystem of the ported open-source HarmonyOS; Add the EROFS compilation item to the ported open-source HarmonyOS and adapt the corresponding build configuration file to obtain the configured build subsystem.

5. The method for integrating and debugging the open-source HarmonyOS read-only file system based on EROFS according to claim 1, characterized in that, After obtaining the open-source HarmonyOS integrated with EROFS, it also includes debugging the open-source HarmonyOS integrated with EROFS. The debugging process specifically includes: Add the EROFS mount item of the HDC debugging command, and the EROFS mount item is used to support remounting and unmounting; Perform mount debugging on the open-source HarmonyOS integrated with EROFS based on the EROFS mount item to obtain the debugged open-source HarmonyOS integrated with EROFS.

6. The method for integrating and debugging the open-source HarmonyOS read-only file system based on EROFS according to claim 5, wherein The performing mount debugging on the open-source HarmonyOS integrated with EROFS based on the EROFS mount item to obtain the debugged open-source HarmonyOS integrated with EROFS includes: Add the overlay environment parameter to the open-source HarmonyOS integrated with EROFS, and the overlay environment parameter is used to determine whether the file system uses the overlay mount type; Adjust the mount partition table of the open-source HarmonyOS integrated with EROFS to obtain the adjusted mount partition table, and the adjusted mount partition table is used to adjust the mount type of the EROFS partition to the overlay mount type; Add the overlay directory creation task to the initialization configuration file, and the overlay directory creation task is used to determine whether to perform the mount operation; Perform mount debugging using the server and the development end installed with the open-source HarmonyOS integrated with EROFS, and add the operation task corresponding to the EROFS mount item to the HDC debugging command of the server, and add the operation task corresponding to the EROFS mount item to the HDC debugging command of the development end.

7. The method for integrating and debugging the open-source HarmonyOS read-only file system based on EROFS according to claim 6, characterized in that, The process of mounting and debugging using the server and development side of the open-source HarmonyOS installed with the integrated EROFS includes: If it is determined to perform a remount operation and the value of the overlay environment parameter is the same as the preset successful mount value, the user is prompted that the overlay is successfully mounted; if it is determined to perform a remount operation and the value of the overlay environment parameter is different from the preset successful mount value, the value of the overlay environment parameter is set to be the same as the preset successful mount value, and an EROFS partition directory is created; if it is determined to perform an umount operation, the value of the overlay environment parameter is cleared, and the EROFS partition directory is deleted; Restart the server and the development side, add an overlay directory creation task to the initialization configuration file and perform a file system mounting operation. If the value of the overlay environment parameter is the same as the preset successful mount value, remount the EROFS partition as the overlay mount type; if the value of the overlay environment parameter is different from the preset successful mount value, mount each partition according to the original fstab configuration.

8. An open-source HarmonyOS read-only file system integration and debugging device based on EROFS, characterized in that, Including: A transplantation module, which is used to transplant the tool set of EROFS into the open-source HarmonyOS to obtain the transplanted open-source HarmonyOS; An adaptation module, which is used to configure the EROFS kernel in the transplanted open-source HarmonyOS, adjust the startup parameters, configure the EROFS partition image configuration file, and optimize the compilation command to obtain the open-source HarmonyOS that supports EROFS; An integration module, which is used to compile, package, and burn the open-source HarmonyOS that supports EROFS to obtain the open-source HarmonyOS integrated with EROFS.

9. An electronic device, characterized in that, Including: A memory, which is used to store executable commands; A processor, which is used to call and run the executable commands in the memory to execute the steps of the method for integrating and debugging the read-only file system of the open-source HarmonyOS based on EROFS according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, Program commands are stored in the computer-readable storage medium, and when the program commands are run by the processor, the method for integrating and debugging the read-only file system of the open-source HarmonyOS based on EROFS according to any one of claims 1-7 is implemented.

Images