Driving implantation method, device and electronic equipment

Abstract

This application provides a driver porting method, apparatus, and electronic device. The driver porting method includes: determining the hardware configuration differences between the first operating system and the second operating system based on a first device tree file of a first operating system and a second device tree file of a second operating system; ensuring that both the first and second operating systems support running on the same hardware platform; adapting and adjusting the second device tree file based on the hardware configuration differences; compiling and converting a first compiled file of the first operating system to obtain a second compiled file suitable for the second operating system; and porting the source code file of the target driver from the first operating system to the second operating system based on the adapted and adjusted second device tree file and second compiled file. The technical solution of this application can achieve end-to-end automated driver porting, improving porting efficiency.

Description

Technical Field

[0001] This application relates to the field of computer software and operating systems, and in particular to a driver porting method, apparatus and electronic device. Background Technology

[0002] With the trend of embedded systems evolving towards multi-ecosystem integration, porting existing Android-based device drivers to new operating systems such as the open-source HarmonyOS has become a key task for hardware manufacturers to achieve cross-platform compatibility and domestic adaptation. However, traditional driver porting methods rely heavily on manual intervention, lack systematic and automated support, and often employ a step-by-step porting strategy with separate design solutions for each project. This lack of reusable and scalable standardized methods to guide the entire process results in a large amount of repetitive work, making the operations not only scattered and cumbersome but also prone to problems such as configuration omissions, logical deviations, and semantic misjudgments. Summary of the Invention

[0003] In view of the above, this application provides a driver porting method, apparatus, and electronic device to solve the problems existing in the prior art. The technical solution is as follows: In a first aspect, embodiments of this application provide a driver porting method, including: Based on the first device tree file of the first operating system and the second device tree file of the second operating system, the hardware configuration differences between the first operating system and the second operating system are determined; both the first operating system and the second operating system support running on the same hardware platform. The second device tree file was adapted and adjusted based on hardware configuration differences; The first compilation file based on the first operating system is compiled and converted to obtain a second compilation file suitable for the second operating system. Based on the adapted and adjusted second device tree file and second compilation file, the source code files of the target driver in the first operating system are ported to the second operating system.

[0004] Secondly, embodiments of this application provide a driver porting device, comprising: The difference determination module is used to determine the hardware configuration differences between the first operating system and the second operating system based on the first device tree file of the first operating system and the second device tree file of the second operating system; both the first operating system and the second operating system support running on the same hardware platform. The device tree adjustment module is used to adapt and adjust the second device tree file based on hardware configuration differences; The compilation and conversion module is used to compile and convert a first compilation file based on a first operating system to obtain a second compilation file suitable for a second operating system. The driver porting module is used to port the source code files of the target driver from the first operating system to the second operating system based on the adapted and adjusted second device tree file and second compilation file.

[0005] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor, wherein the memory stores a computer program, which is loaded and executed by the processor to implement the method provided in the first aspect of embodiments of this application.

[0006] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method provided in the first aspect of embodiments of this application.

[0007] The above-mentioned technical solution of this application can achieve at least the following beneficial effects: This approach enables end-to-end driver porting, targeting the two core carriers: the device tree file and the compiled file. It directly addresses the underlying adaptation requirements of a second operating system (such as the open-source HarmonyOS), achieving deep compatibility between the driver layer and the second operating system. For these two core carriers, the solution in this application can automatically perform corresponding adaptation adjustments or conversions based on their configuration differences between the two operating systems, without requiring any changes to configurations without differences. This minimizes the need for modification, significantly reducing the risk of errors caused by manual intervention and greatly improving the consistency and reliability of the porting process. This solution breaks through the traditional isolated porting model of single projects, realizing a standardized and reusable driver porting framework compatible with multiple ecosystems. It also possesses excellent compatibility evolution capabilities, supporting iterative upgrades of compatibility specifications and significantly reducing subsequent costs and upgrade complexity. Attached Figure Description

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

[0009] Figure 1 A flowchart illustrating a driver porting method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structural framework of a drive transplantation device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structural framework of an electronic device provided in an embodiment of this application. Detailed Implementation

[0010] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0011] It should be noted that, unless otherwise specified, the following embodiments and features can be combined with each other; and, based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0012] It should be noted that this document describes various aspects of embodiments within the scope of the appended claims. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on the embodiments of this application, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0013] First, let's introduce several terms used in the embodiments of this application: Device tree file: A data structure used to describe hardware resources. Its corresponding file formats include dtb (device tree blob), dts (device tree source), and dtsi (device tree source include).

[0014] Compilation files, also known as compilation scripts or compilation dependency files, are compilation rules that guide the build system on how to compile the driver source code, and determine whether the driver can be successfully integrated and loaded in the target operating system.

[0015] In some related driver porting techniques, developers need to make piecemeal modifications to the Android device tree file, manually disassemble the Android compilation logic, and rewrite the compilation files suitable for the open-source HarmonyOS system. The entire process also requires repeated debugging to adapt to the Hardware Driver Foundation (HDF) of the open-source HarmonyOS system. The porting cycle is long, the manpower cost is high, and it seriously affects the progress of product adaptation to the open-source HarmonyOS system. In other related driver porting techniques, although the focus has been on porting at the upper or lower layers of the system, such as the file system (storage architecture adaptation) and abstraction layer (interface mapping), it still relies on a lot of manual reconstruction, which is inefficient.

[0016] This application provides a novel driver porting scheme to solve the aforementioned problems. The scheme can be applied to a first terminal device to port a target driver from a first operating system installed on a second terminal device to a second operating system installed on a third terminal device. The second and third terminal devices can be the same device or different devices; that is, the first and second operating systems can be two operating systems on the same terminal device or operating systems on different terminal devices. For example, if a mobile phone has both Android and open-source HarmonyOS installed, and the target driver for Android needs to be ported to HarmonyOS, then the first operating system can be Android, and the second operating system can be HarmonyOS. Similarly, if phone A has Android installed and phone B has HarmonyOS installed, and the target driver for Android needs to be ported to HarmonyOS, then the first operating system can be Android on phone A, and the second operating system can be HarmonyOS on phone B. The first terminal device can be another device independent of both the first and second terminal devices, and can communicate and connect separately to both.

[0017] The technical solution of this application and how the technology of this application solves the above-mentioned technical problems are described in detail below with specific embodiments.

[0018] This application provides a driver porting method, such as... Figure 1 As shown, the method may include: S101, based on the first device tree file of the first operating system and the second device tree file of the second operating system, determine the hardware configuration differences between the first operating system and the second operating system.

[0019] Both the first and second operating systems support running on the same hardware platform, which includes a unified chip architecture, memory layout, and peripheral interface resources. The first and second operating systems can share the hardware resources provided by the hardware platform. The hardware platform can be an embedded platform. The first operating system can be an Android system or a Linux (an operating system kernel) system, and the second operating system can be an open-source HarmonyOS system or a HarmonyOS system.

[0020] The first device tree file describes the hardware resources of the first operating system, and the second device tree file describes the hardware resources of the second operating system. By comparing the first device tree file and the second device tree file, the differences in hardware configuration between the first operating system and the second operating system can be identified.

[0021] The first device tree file can be obtained from the first terminal device or from the cloud server of the hardware platform vendor via the network. The second device tree file can be obtained from the second terminal device or from the cloud server of the hardware platform vendor via the network. Alternatively, if the first device tree file has already been obtained, it can be decompiled using a decompilation tool to obtain the second device tree file.

[0022] S102, adapt and adjust the second device tree file based on hardware configuration differences.

[0023] S103, compile and convert the first compilation file based on the first operating system to obtain a second compilation file suitable for the second operating system.

[0024] The first compilation file reflects the compilation rules of the first operating system, and the second compilation file reflects the compilation rules of the second operating system.

[0025] S104, based on the adapted and adjusted second device tree file and second compilation file, port the source code file of the target driver in the first operating system to the second operating system.

[0026] The driver porting method provided in this application embodiment can achieve end-to-end driver porting for the two core carriers of the target driver: the device tree file and the compiled file. It directly addresses the underlying adaptation requirements of a second operating system (such as the open-source HarmonyOS), achieving deep compatibility between the driver layer and the second operating system. For the two core carriers, the solution in this application embodiment can automatically complete the corresponding adaptation adjustments or conversions based on their configuration differences in the two operating systems, without requiring any changes to configurations without configuration differences. This minimizes the need for modification, significantly reducing the risk of errors caused by manual intervention and greatly improving the consistency and reliability of the porting process. The solution in this application embodiment breaks through the traditional isolated porting mode of a single project, realizing a standardized and reusable driver porting framework compatible with multiple ecosystems. It also possesses good compatibility evolution capabilities, supporting iterative upgrades of compatibility specifications and significantly reducing subsequent costs and upgrade complexity.

[0027] In an optional implementation, in step S101 above, determining the hardware configuration differences between the first operating system and the second operating system based on the first device tree file of the first operating system and the second device tree file of the second operating system may include: determining the common nodes of the first operating system and the second operating system based on the hardware core configuration information in the first device tree file and the hardware core configuration information in the second device tree file; comparing the first hardware extension information and the second hardware extension information of the common nodes, and determining the difference nodes in the common nodes whose first hardware extension information and second hardware extension information differ based on the comparison result; and extracting the difference portion between the first hardware extension information and the second hardware extension information of the difference nodes.

[0028] The first hardware extended information can be provided by the first device tree file, and the second hardware extended information can be provided by the second device tree file. The aforementioned differences can be used to characterize the hardware configuration differences between the first and second operating systems. The core hardware configuration information may include at least one type of information such as the node path of the hardware node, the compatible attribute field, the address range (reg), and interrupt definitions (interrupts). For example, the node path, compatible field, reg, and interrupts of core peripherals such as the bidirectional two-wire synchronous serial bus (I2C), the serial peripheral interface (SPI), and the universal asynchronous receiver / transmitter (UART). The first hardware extended information may include configuration information such as extended configurations specific to the first operating system, platform vendor-defined attributes, device identification information, and device status. The second hardware extended information may include at least one type of configuration information such as extended configurations specific to the second operating system, platform vendor-defined attributes, device identification information, and device status.

[0029] For example, the first device tree file and the second device tree file can be parsed by a script to extract the core hardware configuration information of the core peripherals for comparison. If the comparison results are consistent (e.g., the core hardware configuration information is the same or compatible), the corresponding core peripheral can be identified as a common node, and a list of common nodes can be generated. Further, the extended function information (i.e., the first extended function information and the second extended function information) of each common node in the list of common nodes can be compared in the two device tree files. If the comparison results show that the first extended function information and the second extended function information are different (e.g., the second extended function information is missing information, or the second extended function information is different from the first extended function information), the corresponding common node can be identified as a difference node and marked in the list of common nodes. The difference part in the first extended function information of the difference node can be extracted. The difference part can be stored in JSON (a lightweight data exchange format) or other formats.

[0030] By identifying common nodes in the first and second device tree files, it is possible to accurately locate the same hardware nodes under the two operating systems. Then, based on a unified hardware node benchmark, by comparing and analyzing their configuration differences, interference from core hardware nodes such as the central processing unit (CPU) and memory controller that do not need to be modified can be filtered out. This allows for the precise location of the difference nodes that are supported by both operating systems and have configuration differences, effectively improving the accuracy and efficiency of difference detection and providing a reliable basis for target-driven porting.

[0031] In another optional implementation, in step S101 above, the hardware configuration differences between the first operating system and the second operating system can also be identified by pattern matching and semantic analysis based on the device tree structure. For example, the complete structure of the first device tree file and the second device tree file can be parsed first, and key fields such as compatible, reg, and interrupts of each hardware node can be extracted. Then, the first device tree file and the second device tree file can be normalized and semantically aligned using a predefined hardware configuration template or rule base to identify the hardware configuration differences.

[0032] In an optional implementation, in step S102 above, adapting the second device tree file based on hardware configuration differences may include performing at least one of the following adaptation adjustments on the second device tree file: adding the aforementioned difference portion to the second hardware extension information of the difference node; modifying or replacing the second hardware extension information of the difference node based on the aforementioned difference portion.

[0033] For a given difference node, the difference node can be accurately located in the second device tree file based on the node path. Based on its second hardware extension information, if the difference part is missing information in the second hardware extension information, the difference part can be directly added to the second hardware extension information. If the difference part is information in the first hardware extension information that is inconsistent with the second hardware extension information, the second hardware extension information can be replaced with the first hardware extension information corresponding to the difference node to form a new second hardware extension information, or the second extended function information can be modified based on the difference part.

[0034] Based on the above implementation method of adaptation and adjustment, the parameters of extended functions can be adjusted without changing the core hardware parameters, so as to realize the intelligent merging of the first device tree file and the second device tree file, thereby ensuring the consistency and compatibility of the initial hardware human-computer interaction strategy before and after driver porting, and enhancing the stability of system integration and development iteration efficiency.

[0035] In an optional implementation, step S103 above, which involves compiling and converting a first compiled file based on a first operating system to obtain a second compiled file suitable for a second operating system, may include: extracting compilation configuration information from the first compiled file; and generating a second compiled file suitable for the second operating system based on the compilation configuration information. The compilation configuration information may include module names, a list of source files, dependent libraries, and installation paths.

[0036] The process of generating a second compiled file suitable for a second operating system based on compilation configuration information can include the following aspects: Regarding module definitions, module names in the first compiled file can be retained and mapped to model types supported by the second operating system to ensure correct module ownership and construction in the second operating system; regarding source code configuration, all source file paths in the source file list can be mapped to the source file (sources) field in the second compiled file, maintaining the path structure to ensure code organization consistency; regarding compilation options, macro definitions specific to the first operating system can be replaced with system macro definitions corresponding to the second operating system, while retaining the original compilation optimization parameters to ensure no loss of performance characteristics; regarding dependency library adaptation, dependency libraries from the first operating system can be replaced with versions compatible with the second operating system to ensure interface availability and runtime compatibility; regarding installation paths, mapping can be performed according to the directory specifications of the second operating system. For example, the target output shared library directory ($(target_out_shared_libraries)) of the first operating system can be converted to the relative installation directory (relative_install_dir) in the second operating system to meet system deployment requirements.

[0037] This implementation method enables automated and standardized mapping and conversion from the first compiled file to the second compiled file, effectively supporting code reuse and engineering integration across operating system environments.

[0038] In another optional implementation, in step S103 above, the compilation conversion based on the first compilation file of the first operating system to obtain a second compilation file suitable for the second operating system may include: pre-building a compilation syntax mapping rule library and template engine from the first operating system to the second operating system. When the first compilation file is input, its structured elements (such as variable assignment, condition judgment, and modules) can be identified by the syntax parser. Then, according to the predefined conversion rules and combined with the build template of the target system (i.e., the second operating system), a second compilation file conforming to the specification is automatically generated. This method does not require explicit extraction of intermediate configuration information, but completes the end-to-end conversion through pattern matching and rule replacement.

[0039] In an optional implementation, the driver porting method provided in this application may further include: performing integrity verification on the registration configuration nodes required by the HDF framework in the first compiled file and the second device tree file; and supplementing the first compiled file and the registration configuration nodes in response to the failure of the integrity verification and the received supplementary information.

[0040] When performing integrity verification on the first compiled file, it can check whether the compilation configuration information in the first compiled file is complete. For example, it can check whether the configuration information such as module name, source file list, dependent libraries and installation path is complete. If there is missing information, it can output the verification failure information, so that developers can understand the verification result in time and input the information to be supplemented based on the result. After receiving the information to be supplemented, the missing information in the first compiled file can be supplemented. After the information is supplemented, the subsequent compilation file conversion process can be carried out.

[0041] When performing integrity verification on the registration configuration nodes required by the HDF framework in the second device tree, it can verify whether the registration configuration nodes required by the HDF framework are complete in the second device tree file, such as whether the HDF root node and service name (service_name) placeholder are complete. If they are incomplete (e.g., missing nodes or incomplete structure), a verification failure message can be output, so that developers can understand the verification result in a timely manner and input the information to be supplemented based on the result. After receiving the information to be supplemented, the above registration configuration nodes can be supplemented to ensure that the driver can register normally.

[0042] Introducing the aforementioned integrity verification mechanism into the critical stages of compiling file conversion and device tree configuration generation can promptly detect missing content and provide feedback on verification failures, guiding developers to supplement the required data or nodes. This reduces the risk of compilation failures and driver registration anomalies caused by configuration omissions, significantly improving the reliability and compatibility of cross-system porting.

[0043] In an optional implementation, the driver porting method provided in this application embodiment may further include: adding the reference label of the difference node in the first device tree file to the service name field of the HDF framework in the second device tree file.

[0044] This implementation can fully utilize the semantic tag information of existing hardware nodes and automatically map it to the driver service name required by the HDF framework. This helps to achieve the unique identification and normal registration of the target driver in the second operating system, ensuring that the HDF service can recognize the driver and avoid driver loading failure due to missing or non-standard service names. At the same time, by inheriting the readable and consistent tags in the source device tree file (i.e., the first device tree file), the maintainability and contextual relevance of the service name are effectively improved, which helps to reduce configuration errors.

[0045] In an optional implementation, the driver porting method provided in this application embodiment may further include: detecting whether there is a device tree adaptation anomaly during the above-mentioned adaptation adjustment process; and / or detecting whether there is a compilation conversion anomaly during the above-mentioned compilation conversion process; and performing corresponding exception handling in response to the existence of device tree adaptation anomaly and / or compilation conversion anomaly.

[0046] The adaptation and adjustment process can include pre-adaptation preparation, execution, and post-adaptation processing. Device tree adaptation anomalies can include at least one of the following: node conflicts and device tree syntax errors. Specifically, a node conflict occurs when a hardware node in the second device tree file has the same name as a hardware node in the first operating system, but their functions conflict (e.g., resource allocation conflicts or device type differences). For this type of anomaly, the adaptation and adjustment process can be paused or terminated, conflict details output (e.g., node path, attribute differences, and source system), and manual intervention is required. A device tree syntax error occurs when the second device tree file contains syntax errors, such as incorrect parameter formats or type mismatches. This error can be detected by a device tree compilation tool (dtc tool). For this type of anomaly, the error can be automatically located, and a prompt message can be output to alert developers for correction.

[0047] The compilation and conversion process can include the execution of the compilation and conversion process and subsequent processing (such as subsequent compilation processes). A specific scenario for a compilation and conversion exception is the detection of missing dependency library data in the second compiled file or the occurrence of dependency missingness during subsequent compilation. The exception handling method for this situation can be to supplement the second compiled file with dependency library data adapted to the second operating system based on a specified dependency library mapping table (such as a dependency library mapping table provided by the hardware platform vendor).

[0048] Based on the above implementation methods, the driver porting method provided in this application introduces a detection mechanism for device tree adaptation anomalies in the adaptation and adjustment process (including pre-processing, execution, and post-processing), and a detection mechanism for compilation and conversion anomalies in the compilation and conversion process. This achieves comprehensive status awareness and risk warning for key aspects of driver porting, significantly improving the robustness and maintainability of the driver porting process. It avoids later build failures or runtime faults caused by hidden errors, enabling early detection, early location, and early repair of problems, and effectively ensuring the integrity, correctness, and automation level of cross-operating system driver migration.

[0049] In an optional implementation, the driver porting method provided in this application embodiment may further include: outputting key verification data of the second operating system before porting the source code file of the target driver in the first operating system to the second operating system; and adjusting the key verification data in response to a received adjustment instruction.

[0050] Key verification data can include at least one of the following: the HDF node's service_name, device matching attributes (device_match_attr), custom compilation options, special dependency libraries, and hardware core configuration information. After output, developers can verify the key verification data to ensure the accuracy of the relevant configurations. For example, they can check whether the HDF node's service name and device matching attributes match the driver identification rules of the target operating system (i.e., the second operating system), whether custom compilation options and special dependency libraries have been omitted due to automatic conversion, and whether core parameters have been modified to prevent non-compliance with compatibility specifications. This manual verification process effectively compensates for potential blind spots in automated processing, improving the reliability and compliance of the porting results.

[0051] The following section uses Android (as the first operating system) and the open-source HarmonyOS (as the second operating system) as examples to introduce the driver porting method provided in the embodiments of this application.

[0052] Extract the .dtb format device tree file (hereinafter referred to as Android device tree file), Android.mk file (i.e. Android compilation file, as the first compilation file) and target driver source file from the Android device to be ported, to ensure that there is no deeply customized kernel logic, and extract the .dts or .dtsi format device tree file (hereinafter referred to as open source HarmonyOS device tree file) from the open source HarmonyOS device.

[0053] The extracted files are verified and preprocessed to confirm file compatibility. Specifically, the integrity of the Android.mk file is verified, and key configurations such as module name, source file list, and dependency libraries are extracted to prepare for subsequent conversion; the HDF root node, service_name, placeholders, etc. required by the HDF framework in the open-source HarmonyOS device tree file are checked to ensure that the driver can be registered normally.

[0054] The Android device tree file is used to extract differential information. Specifically, a script can be used to parse the Android device tree file and the open-source HarmonyOS device tree file, compare the node paths, compatible fields, reg, interrupts and other core parameters of core peripherals such as I2C, SPI, and UART, generate a list of common nodes, compare the key configurations of each common node in the list, mark the types of different nodes in the list based on the comparison results, filter out core nodes in the list that do not need to be modified such as CPU and memory controller, and directly extract the following three types of hardware extended information from the different nodes: Android-specific extended configurations, platform vendor custom attributes, and device identification information, and store them in JSON format.

[0055] Based on compatibility specifications, the three types of hardware extension information extracted from the Android device tree file will be merged into the open-source HarmonyOS device tree. Specifically, using the open-source HarmonyOS device tree file as a benchmark, without modifying the core hardware configuration information of the core peripherals, the difference nodes in the open-source HarmonyOS device tree are accurately located according to the node path. The extracted difference information is added to the corresponding difference node, or the core hardware configuration information of the corresponding difference node is retained, and the hardware extension information is replaced with the adaptation values ​​on the Android side. The modification records are synchronously archived for manual verification. At the same time, the label value of the Android node is filled into the service_name field of the open-source HarmonyOS to ensure that the HDF service can correctly recognize the driver.

[0056] The Android.mk file of the Android system is compiled and converted to obtain the BUILD.gn file suitable for the open source HarmonyOS system (i.e., the open source HarmonyOS compilation file, which serves as the second compilation file). Specifically, regarding module definitions, the names defined in LOCAL_MODULE (local module) in the Android.mk file are directly reused and mapped to the ohos_xxx (HarmonyOS identifier prefix) module type corresponding to the open-source HarmonyOS system. Regarding source code configuration, the file list in LOCAL_SRC_FILES (local source file list configuration item) is directly mapped to the sources field of BUILD.gn, while the file paths remain unchanged. Regarding compilation options, Android system-specific macro definitions are automatically replaced with system macro definitions from the open-source HarmonyOS system, while retaining the original compilation optimization parameters. Regarding dependency library adaptation, Android system dependency libraries (such as the Android log library file liblog) are replaced with manufacturer-specified open-source HarmonyOS compatible versions (such as the HarmonyOS log library file libhilog). Regarding installation paths, based on the open-source HarmonyOS directory layout specifications, $(target_out_shared_libraries) in the Android.mk file is mapped to relative_install_dir in the BUILD.gn file.

[0057] When conflicts and anomalies are encountered, corresponding measures are taken. Specifically, regarding node conflicts, when a hardware node with the same name but conflicting functions is detected between the Android system and the open-source HarmonyOS system, the automatic merging process is paused, detailed conflict information is output, and manual decision-making is required. The final processing result is archived to ensure the security and controllability of critical configurations. Regarding device tree syntax errors, the generated open-source HarmonyOS device tree file is checked for syntax and structure using the dtc tool. Once parameter format errors or type mismatches are found, the system can automatically locate the anomaly and prompt the user to correct it, improving debugging efficiency. Regarding compilation and conversion anomalies, to address the issue of missing dependency libraries that may occur after converting the BUILD.gn file, the system automatically identifies missing items and supplements the appropriate target platform dependency libraries based on the standardized dependency mapping table provided by the manufacturer (e.g., mapping Android's liblog to open-source HarmonyOS's libhilog), ensuring the completeness and usability of the build environment.

[0058] Finally, a manual verification mechanism is used to ensure the accuracy of key configurations. Specifically, key verification data of HDF nodes, such as service_name and device_match_attr, are carefully checked to ensure they strictly comply with the driver identification rules and matching mechanisms of the open-source HarmonyOS system, avoiding driver registration failures due to naming discrepancies or structural inconsistencies. Simultaneously, custom compilation options and special dependency libraries are checked to prevent the omission of critical configuration items during automated conversion. Furthermore, it is rigorously verified that hardware core configuration information explicitly prohibited from modification by the manufacturer has not been altered, ensuring the overall configuration meets compatibility specifications and security requirements.

[0059] Compared to purely manual porting methods, the aforementioned approach of porting drivers from the Android system to the open-source HarmonyOS system demonstrates significant advantages in terms of porting success rate, time and manpower costs, and system stability. The following analysis uses the porting of the audio module driver as an example to compare and analyze the porting results, efficiency, and system stability.

[0060] First, regarding the success rate of porting, the porting scheme of this application is significantly superior to the traditional purely manual porting scheme. Actual test data shows that when using the purely manual porting scheme for audio driver porting, the success rate of achieving a complete match with the original system configuration is approximately 70%, with a high risk of configuration omissions or parameter errors; while when porting using the porting scheme of this application, the corresponding success rate of a complete match with the original system configuration reaches over 95%, greatly improving configuration consistency and functional integrity.

[0061] Secondly, regarding porting efficiency, the porting scheme of this application embodiment can effectively reduce the reliance on the experience level of technical personnel and significantly shorten the development cycle. Even when operated by technical personnel with rich driver development experience, pure manual porting still requires 2 to 3 working days to complete the entire process from driver adaptation to functional verification; while using the porting scheme of this application embodiment, even when operated by technical personnel with relatively less relevant development experience, the same scale of audio module driver porting and functional verification can be efficiently completed within 1 working day, with an overall efficiency improvement of more than 50%.

[0062] Finally, regarding system operational stability, the porting scheme of this application embodiment can effectively improve system operational stability. To evaluate the long-term operating performance of the device after power-on, a 24-hour stability test was conducted, during which the CPU and memory resource usage of key processes were collected every hour using the top command (process monitoring command). The test results show that the device ported manually exhibits large fluctuations in CPU and memory usage, with peak fluctuations reaching approximately 20%, reflecting unstable system resource scheduling and potential issues such as memory leaks or abnormal wake-ups; while the device ported based on this scheme shows more stable resource usage, with CPU and memory fluctuations remaining below 10%, resulting in more stable and reliable overall system operation.

[0063] In summary, the driver porting solution provided in this application not only significantly improves the porting success rate and work efficiency, but also effectively ensures the system stability of the device in actual operation, thus having higher practical value and promotional significance.

[0064] Although the steps of the methods in the embodiments of this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0065] Based on the same technical concept, embodiments of this application also provide a driver porting device, such as... Figure 2 As shown, the driver porting device 200 may include: a difference determination module 201, a device tree adjustment module 202, a compilation and conversion module 203, and a driver porting module 204.

[0066] The difference determination module 201 is used to determine the hardware configuration differences between the first operating system and the second operating system based on the first device tree file of the first operating system and the second device tree file of the second operating system. Both the first operating system and the second operating system support running on the same hardware platform. The adaptation adjustment module is used to adapt and adjust the second device tree file based on the hardware configuration differences. The compilation conversion module 203 is used to compile and convert the first compilation file of the first operating system to obtain a second compilation file suitable for the second operating system. The driver porting module 204 is used to port the source code file of the target driver in the first operating system to the second operating system based on the adapted and adjusted second device tree file and the second compilation file.

[0067] In an optional implementation, when determining the hardware configuration differences between the first operating system and the second operating system, the difference determination module 201 can be used to: determine the common nodes of the first and second operating systems based on the hardware core configuration information in the first device tree file and the hardware core configuration information in the second device tree file; compare the first hardware extension information and the second hardware extension information of the common nodes, and determine the difference nodes in the common nodes where the first hardware extension information and the second hardware extension information are different based on the comparison result; extract the difference portion from the first hardware extension information of the difference nodes and the second hardware extension information of the difference nodes. The first hardware extension information is provided by the first device tree file, and the second hardware extension information is provided by the second device tree file; the difference portion is used to characterize the hardware configuration differences.

[0068] In one optional implementation, when adapting the second device tree file based on hardware configuration differences, the device tree adjustment module 202 can be used to perform at least one of the following adaptation adjustment operations on the second device tree file: adding the difference portion to the second hardware extension information of the difference node; modifying or replacing the second hardware extension information of the difference node based on the difference portion.

[0069] In one optional implementation, when compiling and converting a first compiled file based on a first operating system to obtain a second compiled file suitable for a second operating system, the compilation conversion module 203 can be used to: extract compilation configuration information from the first compiled file and generate a second compiled file suitable for the second operating system based on the compilation configuration information. The compilation configuration information includes module name, source file list, dependent libraries, and installation path.

[0070] In an optional implementation, the driver porting apparatus 200 provided in this application embodiment may further include a verification module and a supplementation module. The verification module is used to perform integrity verification on the registration configuration nodes required by the HDF framework in the first compiled file and the second device tree file, and the supplementation module is used to supplement the first compiled file and the registration configuration nodes in response to the failure of the integrity verification and the received supplementary information.

[0071] In an optional implementation, the device tree adjustment module 202 can also be used to: add the reference tags of the difference nodes in the first device tree file to the service name field of the HDF framework in the second device tree file.

[0072] In an optional implementation, the driver porting device 200 provided in this application embodiment may further include an exception detection module and an exception handling module. The exception detection module is used to: detect whether there is a device tree adaptation exception during the adaptation adjustment process, and / or detect whether there is a compilation conversion exception during the compilation conversion process; the exception handling module is used to: perform corresponding exception handling in response to the existence of device tree adaptation exception and / or compilation conversion exception.

[0073] In an optional implementation, the driver porting apparatus 200 provided in this application embodiment may further include an output module for outputting key verification data of the second operating system before porting the source code file of the target driver from the first operating system to the second operating system. The device tree adjustment module may also be used to adjust the key verification data in response to a received adjustment instruction.

[0074] The functions of each module in the device of this application embodiment can be referred to the corresponding descriptions in the above method embodiments, and will not be repeated here.

[0075] Based on the same technical concept, embodiments of this application also provide an electronic device, which can be manifested in the form of a general-purpose computing device. For example... Figure 3 The illustrated electronic device 300 may include a memory 301 and a processor 302. The memory 301 stores a computer program, which is loaded and executed by the processor 302 to implement any of the driver porting methods provided in the embodiments of this application. The number of memories 301 and processors 302 may be one or more.

[0076] The aforementioned memory 301 may include at least one of non-volatile memory and volatile memory. Non-volatile memory may include at least one of the following: read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, etc. Volatile memory may include random access memory (RAM) used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), sync link dynamic random access memory (SLDRAM), direct memory bus RAM (DR RAM), etc.

[0077] The aforementioned memory 301 may also include a program / utility having a set (at least one) of program modules, including but not limited to: an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. The aforementioned memory 301 may also be referred to as a storage medium or storage device, and the embodiments of this application do not impose any limitations on this.

[0078] The processor 302 described above can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete device components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor 302 described above can be a processor supporting Advanced Reduced Instruction Set Machines (ARM) architecture.

[0079] Optionally, if the memory 301 and processor 302 are implemented independently, the memory 301 and processor 303 can be interconnected via a bus to communicate with each other. This bus can be at least one of the following: Industry Standard Architecture (ISA) bus, Peripheral Component Interconnect (PCI) bus, Extended Industry Standard Architecture (EISA) bus, etc. The bus can represent one or more of several bus architectures, including a memory bus or memory controller, peripheral bus, graphics acceleration port, processor, or a local bus using any of the various bus architectures.

[0080] Optionally, if the memory 301 and the processor 302 are integrated on a single chip, the memory 301 and the processor 302 can communicate with each other through the internal communication interface 303.

[0081] The aforementioned electronic device can communicate with one or more external devices (e.g., keyboards, pointing devices, Bluetooth devices, etc.), and also with one or more devices that enable users to interact with the electronic device, and / or with any device that enables the electronic device to communicate with one or more other computing devices (e.g., routers, modems, etc.). This communication can be performed via input / output (I / O) interfaces. Furthermore, the aforementioned electronic device can also communicate with one or more networks via a network adapter, such as a Local Area Network (LAN), a Wide Area Network (WAN), or a public network (e.g., the Internet). The network adapter communicates with other modules of the electronic device via a bus. It should be understood that other devices and / or software modules can be used in conjunction with the electronic device, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, Redundant Arrays of Independent Disks (RAID) systems, tape drives, and data backup storage systems.

[0082] The electronic device according to this embodiment of the present application is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present application.

[0083] Based on the same technical concept, embodiments of this application also provide a computer-readable storage medium storing program code, which, when executed by a processor, implements any of the driver porting methods provided in embodiments of this application.

[0084] In exemplary embodiments of this application, a computer-readable storage medium is also provided, on which a program product capable of implementing the methods described above is stored. In some possible implementations, various aspects of this application may also be implemented as a program product comprising program code that, when run on a terminal device, causes the terminal device to perform the steps of the various exemplary embodiments of this application described in the "Exemplary Methods" section above.

[0085] The above-described program product can be produced using any combination of one or more readable media. The readable media can be a readable signal medium or a readable storage medium.

[0086] A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a readable storage medium (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0087] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying readable program code. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0088] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0089] Through the description of the above embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software, or by combining software with necessary equipment. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, mobile hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, mobile terminal, or network device, etc.) to execute the method provided according to the embodiments of this application.

[0090] Those skilled in the art will understand that various aspects of this application can be implemented as a system, method, or program product. Therefore, various aspects of this application can be specifically implemented as: a complete device implementation, a complete software implementation (including firmware, microcode, etc.), or an implementation combining device and software aspects, collectively referred to herein as a "circuit," "module," or "system."

[0091] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0092] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of this application, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0093] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0094] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A driver porting method, characterized in that, include: Based on the first device tree file of the first operating system and the second device tree file of the second operating system, the hardware configuration differences between the first operating system and the second operating system are determined; both the first operating system and the second operating system support running on the same hardware platform. The second device tree file is adapted and adjusted based on the aforementioned hardware configuration differences; A second compiled file suitable for the second operating system is obtained by compiling and converting the first compiled file based on the first compiled file of the first operating system. Based on the adapted and adjusted second device tree file and the second compilation file, the source code file of the target driver in the first operating system is ported to the second operating system.

2. The method according to claim 1, characterized in that, The determination of hardware configuration differences between the first operating system and the second operating system, based on the first device tree file of the first operating system and the second device tree file of the second operating system, includes: Based on the hardware core configuration information in the first device tree file and the hardware core configuration information in the second device tree file, the common nodes of the first operating system and the second operating system are determined. By comparing the first hardware extension information and the second hardware extension information of the shared node, and based on the comparison result, the nodes in the shared node whose first hardware extension information and second hardware extension information are different are determined; the first hardware extension information is provided by the first device tree file, and the second hardware extension information is provided by the second device tree file. Extract the difference portion between the first hardware extension information of the difference node and the second hardware extension information of the difference node; the difference portion is used to characterize the hardware configuration difference.

3. The method according to claim 2, characterized in that, The adaptation and adjustment of the second device tree file based on the hardware configuration differences includes performing at least one of the following adaptation and adjustment operations on the second device tree file: Add the difference portion to the second hardware extension information of the difference node; Based on the differences, the second hardware extension information of the difference node is modified or replaced.

4. The method according to any one of claims 1-3, characterized in that, The process of compiling and converting a first compiled file based on the first operating system to obtain a second compiled file suitable for the second operating system includes: Extract compilation configuration information from the first compiled file; the compilation configuration information includes module name, source file list, dependent libraries, and installation path; A second compiled file suitable for the second operating system is generated based on the compiled configuration information.

5. The method according to any one of claims 1-3, characterized in that, Also includes: Perform integrity verification on the registration configuration nodes required for the hardware driver infrastructure in the first compiled file and the second device tree file; In response to the failure of the integrity check and the received supplementary information, the first compiled file and the registered configuration node are supplemented.

6. The method according to any one of claims 1-3, characterized in that, Also includes: Add the reference tag of the difference node in the first device tree file to the service name field of the hardware driver infrastructure in the second device tree file.

7. The method according to any one of claims 1-3, characterized in that, Also includes: During the adaptation and adjustment process, it is detected whether there is a device tree adaptation anomaly, and / or, during the compilation and conversion process, it is detected whether there is a compilation and conversion anomaly. In response to the existence of the device tree adaptation exception and / or the compilation conversion exception, perform the corresponding exception handling.

8. The method according to any one of claims 1-3, characterized in that, Also includes: Before porting the source code files of the target driver in the first operating system to the second operating system, output the key verification data of the second operating system; In response to the received adjustment instruction, the key verification data is adjusted.

9. A drive-transplantation device, characterized in that, include: The difference determination module is used to determine the hardware configuration differences between the first operating system and the second operating system based on the first device tree file of the first operating system and the second device tree file of the second operating system; both the first operating system and the second operating system support running on the same hardware platform; The device tree adjustment module is used to adapt and adjust the second device tree file based on the hardware configuration differences; The compilation and conversion module is used to compile and convert a first compilation file based on the first operating system to obtain a second compilation file suitable for the second operating system. The driver porting module is used to port the source code files of the target driver in the first operating system to the second operating system based on the adapted and adjusted second device tree file and the second compilation file.

10. An electronic device, characterized in that, include: A memory and a processor, wherein the memory stores a computer program, which is loaded and executed by the processor to implement the method as described in any one of claims 1-8.

Images