Driver cross-platform transplantation method and device, storage medium and electronic equipment

Abstract

The embodiment of the invention provides a driver cross-platform transplantation method and device, a storage medium and electronic device.The method comprises the steps that a set of first source driving blocks and a set of second source driving blocks corresponding to source driver codes of a source platform are obtained; the source driving program code is divided into a plurality of source driving blocks, a group of first source driving blocks are code blocks which do not allow direct cross-platform transplantation, and a group of second source driving blocks are code blocks which allow direct cross-platform transplantation; obtaining a transplantation rule table of each first source driving block in the group of first source driving blocks, and modifying each first source driving block according to the transplantation rule table of each first source driving block to obtain a group of modified first source driving blocks; and based on the modified group of first source driving blocks and the modified group of second source driving blocks, generating a target driving program code, and through the method and the device, the problem of low development efficiency of a computer driving program caused by manual transplantation in related technologies is solved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer software technology, and in particular to a method, device, storage medium and electronic device for cross-platform migration of a driver. Background Art

[0002] With the rapid development of technology, the hardware platforms in the computer field have become very diverse, which means that after a driver is released, it is necessary to adapt it to various hardware platforms, which requires repeated porting and development of the released driver. Currently, the porting of cross-platform hardware drivers is generally done manually by professional technicians in related technical fields.

[0003] However, the field of embedded systems includes a large number of hardware platforms and architectures, each of which has its own specific interfaces, protocols and characteristics. The existing manual cross-platform transplantation methods require a large amount of development work and have the problem of low efficiency in computer driver development. Summary of the invention

[0004] The embodiments of the present application provide a method, device, storage medium and electronic device for cross-platform driver migration, so as to at least solve the problem of low efficiency of computer driver development caused by manual migration in the related art.

[0005] According to one aspect of an embodiment of the present application, a driver program cross-platform porting method is provided, comprising: obtaining a group of first source driver blocks and a group of second source driver blocks corresponding to a source driver program code of a source platform; the source driver program code is divided into multiple source driver blocks, the group of first source driver blocks are code blocks that do not allow direct cross-platform porting, and the group of second source driver blocks are code blocks that allow direct cross-platform porting; obtaining a porting rule table for each first source driver block in the group of first source driver blocks, and modifying each first source driver block according to the porting rule table of each first source driver block to obtain a modified group of first source driver blocks; generating a target driver program code based on the modified group of first source driver blocks and the group of second source driver blocks, and deploying the target driver program code to a target platform.

[0006] According to another aspect of an embodiment of the present application, a driver program cross-platform transplantation device is provided, comprising: a code acquisition module, used to obtain a group of first source driver blocks and a group of second source driver blocks corresponding to a source driver program code of a source platform; the source driver program code is divided into multiple source driver blocks, the group of first source driver blocks are code blocks that do not allow direct cross-platform transplantation, and the group of second source driver blocks are code blocks that allow direct cross-platform transplantation; a transplantation rule module, used to obtain a transplantation rule table of each first source driver block in the group of first source driver blocks, and modify each first source driver block according to the transplantation rule table of each first source driver block to obtain the modified group of first source driver blocks; a code generation module, used to generate a target driver program code based on the modified group of first source driver blocks and the group of second source driver blocks, and deploy the target driver program code to a target platform.

[0007] According to another aspect of the embodiments of the present application, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the above-mentioned driver program cross-platform porting method when running.

[0008] According to another aspect of an embodiment of the present application, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the driver program cross-platform porting method through the computer program.

[0009] According to another aspect of the embodiments of the present application, a computer program product is provided, including a computer program, which, when executed by a processor, implements the steps in any of the above-mentioned driver program cross-platform transplantation method embodiments.

[0010] Through the embodiment of the present application, the source driver code is divided into multiple source driver blocks, and the first source driver block that does not allow direct cross-platform transplantation and the second source driver block that allows direct cross-platform transplantation are identified. By subdividing the code blocks, the code parts that need to be transplanted can be more accurately identified, which significantly reduces the manual workload on code identification and classification, and provides a transplant rule table for each first source driver block, and the first source driver block is modified according to the transplant rule table to obtain a modified first source driver block. By providing a detailed transplant rule table, the source driver code can be automatically modified according to the software and hardware information of the target platform, thereby reducing the cost and time of manual transplantation, improving the efficiency of computer driver development, and solving the problem of complex driver development; further, based on the modified first source driver block and the second source driver block, the target driver code is automatically generated and deployed to the target platform. By automatically generating and deploying the target driver code, the automation level of the entire computer source driver code transplantation process is greatly improved, and the driver code generation of multiple platforms and multiple operating systems is supported, thereby improving the efficiency of computer driver development, and solving the problem of low computer driver development efficiency caused by manual transplantation in related technologies. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 It is a hardware structure block diagram of an optional driver program cross-platform transplantation method according to an embodiment of the present application;

[0012] Figure 2 is a flowchart of an optional driver program cross-platform transplantation method according to an embodiment of the present application;

[0013] Figure 3 is a flow chart of an optional automatic migration driver according to an embodiment of the present application;

[0014] Figure 4 It is an overall flow chart of an optional automatic transplantation of source driver code according to an embodiment of the present application;

[0015] Figure 5 is a structural block diagram of an optional driver program cross-platform transplantation device according to an embodiment of the present application;

[0016] Figure 6 It is a structural block diagram of an optional electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0017] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0018] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0019] According to one aspect of an embodiment of the present application, a method for cross-platform migration of a driver is provided. Optionally, in this embodiment, the method for cross-platform migration of a driver can be applied to Figure 1 In the hardware environment composed of the terminal device 102 and the server 104 shown in FIG. Figure 1 As shown, the server 104 is connected to the terminal device 102 via a network, and can be used to provide services (such as application services, etc.) for the terminal or a client installed on the terminal. A database can be set on the server or independently of the server to provide data storage services for the server 104. Cloud computing and / or edge computing services can be configured on the server or independently of the server to provide data computing services for the server 104.

[0020] The network may include but is not limited to at least one of the following: wired network, wireless network. The wired network may include but is not limited to at least one of the following: wide area network, metropolitan area network, local area network, and the wireless network may include but is not limited to at least one of the following: WIFI, Bluetooth. The terminal device 102 may not be limited to a PC, a mobile phone, a tablet computer, or other devices.

[0021] The driver program cross-platform transplantation method of the embodiment of the present application can be executed by the terminal device 102, or can be executed by the server 104 and the terminal device 102 together. Taking the driver program cross-platform transplantation method of the embodiment executed by the terminal device 102 as an example, Figure 2FIG. 1 is a flow chart of an optional method for cross-platform driver program transplantation according to an embodiment of the present application. Figure 2 As shown, the process of the method may include the following steps:

[0022] Step S202, obtaining a group of first source driver blocks and a group of second source driver blocks corresponding to the source driver code of the source platform; the source driver code is divided into multiple source driver blocks, a group of first source driver blocks are code blocks that do not allow direct cross-platform transplantation, and a group of second source driver blocks are code blocks that allow direct cross-platform transplantation.

[0023] The source driver code refers to the driver code written for a specific source platform (such as a hardware platform or an operating system) and is used to implement the interaction between the device and the operating system.

[0024] Source driver block refers to the code segment or module in which the source driver code is further subdivided, and each source driver block is responsible for implementing a specific function or operation.

[0025] The first source driver block is a code block in the source driver code that does not allow direct cross-platform porting. The first source driver block is usually closely related to the specific hardware interface, protocol or characteristics of the source platform and needs to be modified or replaced accordingly to adapt to the target platform.

[0026] The second source driver block is a block of code in the source driver code that allows direct cross-platform porting. The second source driver block is usually not dependent on the hardware interface or protocol of a specific platform, so it can be used on the target platform without modification.

[0027] Optionally, the terminal device parses the source driver code of the source platform, identifies and divides multiple source driver blocks, and divides the multiple source driver blocks into a group of first source driver blocks and a group of second source driver blocks according to the function of each source driver block and its association with the platform.

[0028] Step S204, obtaining a migration rule table of each first source driver block in a group of first source driver blocks, and modifying each first source driver block according to the migration rule table of each first source driver block to obtain a modified group of first source driver blocks.

[0029] The migration rule table refers to a detailed list of modification rules or steps required to migrate each first source driver block from a source platform to a target platform for each first source driver block. For example, the migration rule table includes modifying function names, modifying variable order, replacing specific API calls, etc.

[0030] Optionally, for each identified first source driver block, the terminal device searches the corresponding transplantation rule table, and modifies each first source driver block item by item according to the guidance in the transplantation rule table to ensure that each modified first source driver block can run correctly on the target platform, thereby obtaining a modified set of first source driver blocks.

[0031] Step S206: Generate target driver program code based on the modified set of first source driver blocks and the modified set of second source driver blocks, and deploy the target driver program code to the target platform.

[0032] The target driver code refers to the driver code that has been modified and integrated so that it can run normally on the target platform and realize the interaction between the device and the operating system.

[0033] The target platform refers to the hardware or operating system environment where the target driver code will eventually be deployed and run.

[0034] Optionally, the terminal device integrates the modified first source driver block and the unmodified second source driver block to form a complete target driver code, and deploys the generated target driver code to the target platform.

[0035] Through the above steps S202 to S206, the source driver code is divided into multiple source driver blocks, and the first source driver block that does not allow direct cross-platform transplantation and the second source driver block that allows direct cross-platform transplantation are identified. By subdividing the code blocks, the code part that needs to be transplanted can be more accurately identified, which significantly reduces the manual workload on code identification and classification, and provides a transplant rule table for each first source driver block, and the first source driver block is modified according to the transplant rule table to obtain a modified first source driver block. By providing a detailed transplant rule table, the source driver code can be automatically modified according to the software and hardware information of the target platform, thereby reducing the cost and time of manual transplantation, improving the efficiency of computer driver development, and solving the problem of complex driver development; further, based on the modified first source driver block and the second source driver block, the target driver code is automatically generated and deployed to the target platform. By automatically generating and deploying the target driver code, the automation level of the entire computer source driver code transplantation process is greatly improved, and the driver code generation of multiple platforms and multiple operating systems is supported, thereby improving the efficiency of computer driver development, and solving the problem of low computer driver development efficiency caused by manual transplantation in related technologies.

[0036] In an exemplary embodiment, each of the plurality of source driver blocks corresponds to first semantic data; the first semantic data corresponding to each source driver block is used to describe the meaning of the elements in each source driver block.

[0037] The first semantic data refers to metadata describing the meaning of an element in the source driver block, for example, the first semantic data includes the function, role, and interaction mode with hardware or operating system of the element.

[0038] In some embodiments, obtaining a set of first source driver blocks and a set of second source driver blocks corresponding to a source driver code of a source platform includes:

[0039] 1. Match the first semantic data corresponding to each source driver block with a plurality of second semantic data stored in a pre-established source driver block semantic library; each of the plurality of second semantic data is used to describe information in the source driver code that is not allowed to be directly transplanted across platforms.

[0040] The source driver block semantic library refers to a pre-established database in which a plurality of second semantic data are stored.

[0041] The second semantic data is used to describe information in the source driver code that cannot be directly transplanted across platforms. The second semantic data is closely related to a specific hardware platform or operating system. For example, the second semantic data is closely related to a specific hardware interface, an operating system call, etc.

[0042] Optionally, Figure 3 FIG. 1 is a flowchart of an automatic migration driver in one embodiment. Figure 3 As shown, the terminal device generates or extracts corresponding first semantic data for each source driver block, and for each source driver block, matches its corresponding first semantic data with the second semantic data in the source driver block semantic library, specifically comparing the descriptions, keywords, tags and other information between the first semantic data and the second semantic data to determine whether there is a match.

[0043] 2. Among the multiple source driver blocks, source driver blocks whose corresponding first semantic data have matching second semantic data are determined as first source driver blocks to obtain a group of first source driver blocks.

[0044] Optionally, the terminal device checks whether the first semantic data corresponding to each source driver block is similar to or corresponds to the second semantic data in the source driver block semantic library. If the first semantic data corresponding to the source driver block finds matching second semantic data in the source driver block semantic library, the source driver block semantic library returns a successful match message, the terminal device triggers the transplantation operation, and determines the source driver block as the first source driver block, and adds it to the group corresponding to the first source driver block to obtain a group of first source driver blocks.

[0045] 3. Determine, among the multiple source driver blocks, source driver blocks whose corresponding first semantic data do not have matching second semantic data as second source driver blocks, to obtain a group of second source driver blocks.

[0046] Optionally, if the first semantic data corresponding to the source driver block does not find matching second semantic data in the source driver block semantic library, the terminal device determines the source driver block as a second source driver block and adds it to the group corresponding to the second source driver block to obtain a group of second source driver blocks.

[0047] like Figure 3 As shown, after the target driver code is generated, in order to facilitate the maintenance and update of the target driver code, a target driver block semantic library corresponding to the target driver code is pre-built, and the target driver block semantic library stores semantic data corresponding to each code block in the target driver code.

[0048] Through this embodiment, corresponding first semantic data is generated for each source driver block, and the meaning of its elements is described, so as to more accurately understand the functions and characteristics of the source driver block, and match the first semantic data with the second semantic data in the pre-established source driver block semantic library. This process is automated and efficient, and can quickly identify which source driver blocks contain information that does not allow direct cross-platform transplantation. Compared with traditional manual review methods, this semantic-based matching method greatly improves recognition efficiency and accuracy, and reduces misclassification caused by human judgment errors.

[0049] In an exemplary embodiment, obtaining a migration rule table of each first source driver block in a group of first source driver blocks includes:

[0050] According to the first semantic data corresponding to each first source driver block, a transplantation rule table corresponding to each first source driver block is searched from multiple transplantation rule tables stored in a pre-established transplantation rule library; each transplantation rule table in the multiple transplantation rule tables is used to describe the rules for transplanting a code block to a target platform.

[0051] Among them, the transplant rule library refers to a pre-established storage library, which contains multiple transplant rule tables, each of which is used to describe the rules for transplanting a code block (for example, a source driver block in the embodiment of the present application) to a target platform.

[0052] The migration rule table refers to a table in the migration rule library that specifically describes how to migrate a code block (such as a source driver block) to a target platform according to specific rules.

[0053] Alternatively, if Figure 3As shown, for each determined first source driver block, after the terminal device triggers the transplantation operation, the terminal device extracts the corresponding first semantic data, accesses the pre-established transplantation rule library, uses the first semantic data of each first source driver block as a keyword, searches for a transplantation rule table that matches it in the transplantation rule library, and for each first source driver block found, determines its corresponding transplantation rule table, and extracts specific transplantation rules from it, and according to the determined transplantation rules, modifies and adjusts the first source driver block so that it can run normally on the target platform.

[0054] Through this embodiment, according to the first semantic data corresponding to each first source driver block, the transplantation rule table corresponding to each first source driver block is searched from multiple transplantation rule tables stored in a pre-established transplantation rule library. Through semantic matching, the first source driver blocks that need to be transplanted and modified can be identified more accurately, reducing the time for manual identification and judgment; through automated rule search and rule-based transplantation, most of the transplantation work can be completed automatically, reducing the links of manual intervention and improving the efficiency and accuracy of transplantation.

[0055] In an exemplary embodiment, the existing computer driver development itself has high complexity and requires a lot of time, energy and cost. Specifically, driver development involves interaction with the underlying hardware, and requires a deep understanding of complex knowledge such as operating systems, hardware interfaces, interrupt processing, and memory management, which requires developers to have deep programming skills and rich work experience. In addition, it is difficult to update and maintain existing computer drivers, which is specifically manifested as follows: embedded systems usually run in a resource-constrained environment. Once the hardware platform changes, such as upgrading the processor, replacing the memory, etc., it may be necessary to rewrite or modify the driver code to adapt to the new environment. In this embodiment, in the face of the above industry pain points, by introducing a large language model, with the help of massive knowledge training, by analyzing the software and hardware information of the target platform, it can automatically analyze the software and hardware information of the target platform, and automatically generate the target driver code of the target platform in combination with the knowledge of the source platform, thereby greatly reducing the workload of code development and improving the development efficiency and quality of the overall project. Specifically, according to the transplantation rule table of each first source driver block, each first source driver block is modified to obtain a modified set of first source driver blocks, including:

[0056] 1. Generate a prompt word corresponding to each first source driver block according to each first source driver block and the transplantation rule table of each first source driver block; the prompt word corresponding to each first source driver block is used to prompt the transplantation method of each first source driver block.

[0057] The prompt word refers to a short sentence or keyword generated according to each first source driver block and its corresponding migration rule table, which is used to guide or prompt the operation of making specific modifications to the large language model. The prompt word is used to clarify the migration method of each first source driver block.

[0058] Alternatively, if Figure 3 As shown, the terminal device parses each rule in the migration rule table of each first source driver block, clarifies the specific meaning and required operation of each rule, and generates a prompt word corresponding to each first source driver block according to the parsed migration rules and the specific content of each first source driver block.

[0059] Second, by calling the model interface of the pre-trained large language model, each first source driver block is modified according to the prompt word corresponding to each first source driver block to obtain a modified group of first source driver blocks.

[0060] Among them, a large language model refers to an artificial intelligence model that is trained with a large amount of data. It has the ability to deeply understand language and can autonomously generate language content. Large language models are usually based on deep learning technology and can capture the complexity and diversity of language, thus playing an important role in the field of natural language processing (NLP). Through pre-training and fine-tuning steps, large language models can be widely used in various tasks such as text generation, natural language understanding, question-answering systems, and language translation.

[0061] In some embodiments, the training process of the large language model includes the following steps:

[0062] 1) In the field of computer driver development, collect and prepare original code blocks and context texts of the code blocks; the context texts are used to describe the rules for porting the code blocks to a specified platform.

[0063] 2) Design prompt words based on the code block and the context text of the code block, such as modifying the source driver block in combination with the migration rules.

[0064] 3) Generate label data corresponding to the code block according to the target code block after the code block is transplanted to the specified platform; wherein the target code block refers to the code block after the code block is adjusted according to the software and hardware information of the specified platform.

[0065] 4) The code block, the prompt word corresponding to the code block and the label data are input into the large language model, the large language model is trained, and the large language model outputs the predicted code block corresponding to the code block.

[0066] 5) According to the difference between the predicted code block and the label data corresponding to the code block, adjust the parameters of the large language model and continue training until the preset training stop condition is reached, such as reaching the maximum number of training times or the accuracy of the large language model meets the requirements, to obtain a trained large language model.

[0067] Alternatively, if Figure 3 As shown, the terminal device calls the model interface of the pre-trained large language model and inputs the generated prompt words and the corresponding first source driver blocks. The large language model performs corresponding modification operations, such as code refactoring, logic adjustment, etc., based on the input prompt words and the content of the first source driver blocks to meet the requirements in the transplantation rule table. Finally, the large language model will output a modified set of first source driver blocks.

[0068] Through this embodiment, a large language model is used to analyze the target hardware and operating system platform, extract a group of first source driver blocks of the source platform, and generate prompt words corresponding to each first source driver block in combination with the rule information of the transplantation rule library, wherein the prompt words accurately reflect the transplantation and modification operations that need to be performed on each first source driver block, and provide clear guidance for subsequent automated modifications. In addition, the large language model can also modify the first source driver block according to the prompt words corresponding to each first source driver block to obtain the modified first source driver block, thereby realizing automated transplantation of the driver program. Compared with the traditional manual transplantation method, the use of a large language model can reduce a large amount of repetitive labor and significantly improve the development efficiency of computer drivers.

[0069] In an exemplary embodiment, each first source driver block is used as a current first source driver block to perform the following filling operation to obtain a prompt word corresponding to each first source driver block:

[0070] 1. Obtain a pre-established prompt word template; the prompt word template includes a code area and a transplant rule area.

[0071] The prompt word template is a structured document, which contains two main areas: a code area and a migration rule area, which are respectively used to fill in the code content of the current first source driver block and its corresponding migration rule.

[0072] 2. Fill the current first source driver block into the code area in the prompt word template, and fill the migration rule table of the current first source driver block into the migration rule area in the prompt word template to obtain the filled prompt word template.

[0073] Optionally, the terminal device reads the code content of the first source driver block that currently needs to be transplanted or modified, fills the read code content of the first source driver block into the code area of ​​the prompt word template, searches for the transplant rule table corresponding to the current first source driver block, and fills the content of the found transplant rule table into the transplant rule area of ​​the prompt word template.

[0074] For example, an exemplary prompt word template is as follows:

[0075] / *Code content* /

[0076] Please perform code migration and modification according to the following rules:

[0077] / Migration rules table * /

[0078] Please return the modified C language code.

[0079] 3. Generate a prompt word corresponding to the current first source driver block according to the content of the filled prompt word template.

[0080] Optionally, the terminal device generates a specific prompt word for the current first source driver block in combination with the content of the code area and the migration rule area in the filled prompt word template.

[0081] Through this embodiment, by utilizing a pre-established prompt word template, combined with the code content of the current first source driver block and its corresponding transplantation rule table, prompt words for guiding code modification can be efficiently generated, thereby reducing manual errors and improving the efficiency of transplantation and modification; in addition, the specific source driver block and the transplantation rules are combined with the prompt word template to generate a customized prompt word template for the current source driver block, thereby reducing the workload of manual identification and filling and improving the transplantation efficiency.

[0082] In an exemplary embodiment, before deploying the target driver code to the target platform, the driver cross-platform porting method further includes:

[0083] 1. Build a cross-compilation environment corresponding to the target platform based on the software and hardware information of the target platform.

[0084] Among them, a cross-compilation environment is a compilation environment in which the compiler runs on one platform, but the target code generated in the cross-compilation environment is designed for another platform (i.e., the target platform). The cross-compilation environment allows developers to compile a program on one platform that can run on another platform.

[0085] Optionally, Figure 4 FIG. 1 is an overall flow chart of the automatic transplantation of source driver code in one embodiment, as shown in FIG. Figure 4As shown, after the source driver code is transplanted using the large language model, the target driver code is obtained, and the semantic data of each code block in the target driver code is stored in the target driver block semantic library. In the process of building the compilation environment, the terminal device extracts the semantic data of each code block from the target driver block semantic library, collects the software and hardware information of the target platform, including the processor type, operating system version, memory size, etc., selects the appropriate compiler and tool chain based on the collected information, and configures the compilation environment, including setting environment variables, installing necessary dependent libraries, etc., to ensure that the compiler can correctly generate the code for the target platform, thereby obtaining a cross-compilation environment corresponding to the target platform.

[0086] 2. In the cross-compilation environment, use pre-built test cases to test the target driver code and obtain code test results.

[0087] A test case is a set of inputs, execution conditions, and expected outputs designed to verify whether the target driver code works as expected. Test cases are used to test the correctness, stability, and performance of the target driver code.

[0088] Code test results refer to the evaluation results of the performance of the target driver code on the target platform after executing the test case, including whether the test passed, whether there are errors or exceptions, etc.

[0089] Optionally, the terminal device imports the target driver code into a cross-compilation environment, selects or writes test cases related to the target driver code, compiles the test cases and the target driver code in the cross-compilation environment, generates a binary file that can be run on the target platform, deploys the generated binary file to the target platform, runs the test cases, and records the code test results, including the pass status of the test cases, error logs, performance data, etc.

[0090] like Figure 3 As shown, during the compilation process, a compilation error solution knowledge base is pre-built, and a plurality of compilation error solutions are stored in the compilation error solution knowledge base. If a compilation error occurs during the compilation process, the corresponding error solution can be found in the compilation error solution knowledge base.

[0091] 3. Adjust the target driver code according to the code test results to make the target driver code run normally on the target platform.

[0092] Optionally, the terminal device analyzes the code test results to determine which test cases have failed or have anomalies, locates the problems or deficiencies in the target driver code based on the test results, and makes necessary modifications and optimizations to the code to fix the problems or improve performance. The process of problem location and code modification is repeated until all test cases have passed and the code performs stably on the target platform.

[0093] Through this embodiment, according to the software and hardware information of the target platform, a suitable cross-compilation environment is automatically constructed, and test cases are generated for automated testing to verify the effectiveness and reliability of the generated target driver code, find and repair potential problems in the target driver code, thereby improving the quality and stability of the code. In addition, the construction of the source driver block semantic library, the transplant rule library, the generation of the target driver code, and the whole process of compiling and testing are all automated, which greatly improves the development efficiency.

[0094] In an exemplary embodiment, before deploying the target driver code to the target platform, the driver cross-platform porting method further includes:

[0095] 1. Based on preset indicators, the quality of the adjusted target driver code is evaluated to obtain a quality evaluation result.

[0096] The preset indicators refer to a series of standards or requirements used to measure the quality of the target driver code during the quality assessment process. For example, the preset indicators include code readability, maintainability, performance, security and other aspects.

[0097] The quality assessment result refers to the conclusion drawn after quality assessment of the target driver code, which is used to characterize the quality status of the code, including whether there are risks and whether it is safe.

[0098] Alternatively, if Figure 4 As described above, the terminal device determines the specific content and requirements of the preset indicators, uses appropriate evaluation tools or methods to evaluate the target driver code after the cross-compilation test item by item, and checks whether the code meets the requirements of the preset indicators. After the evaluation is completed, the quality evaluation result is obtained to determine whether there is a risk in the code.

[0099] 2. When the quality assessment result indicates that the target driver code has risks, adjust the target driver code and re-perform quality assessment on the adjusted target driver code until the re-evaluated quality assessment result indicates that the target driver code is safe and triggers the step of deploying the target driver code to the target platform.

[0100] Optionally, if the quality assessment result indicates that the target driver code after the cross-compilation test has risks, the terminal device will adjust the target driver code after the cross-compilation test again, such as fixing errors in the code, optimizing the code structure, improving code performance, etc. After the adjustment is completed, the terminal device uses the same assessment tool or method to re-evaluate the adjusted target driver code until the re-evaluated quality assessment result indicates that the target driver code is safe and risk-free, ensuring that the modification does not introduce new problems. When the quality assessment result finally indicates that the target driver code is safe, the terminal device deploys the final adjusted target driver code to the target platform.

[0101] Through this embodiment, the security and stability detection and quality assessment of the generated code are carried out in combination with artificial intelligence technology. Through the built-in security mechanism and strict testing process, it is ensured that the generated target driver code meets the security standards and reduces potential risks. It can ensure that the target driver code has undergone strict quality assessment and adjustment before being deployed to the target platform, which can effectively reduce the risk of problems in the actual operation of the code and improve the reliability and security of the code. At the same time, through the automated and standardized evaluation process, the efficiency and quality of driver development are also improved.

[0102] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0103] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware server, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM (Read-Only Memory) / RAM (Random Access Memory), a disk, or an optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods of each embodiment of the present application.

[0104] According to another aspect of the embodiment of the present application, a driver program cross-platform transplantation device is also provided, and the device is used to implement the driver program cross-platform transplantation method provided in the above-mentioned embodiment, and the description thereof has been made without further details. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the device described in the following embodiments is preferably implemented with software, the implementation of hardware, or a combination of software and hardware is also possible and conceived.

[0105] Figure 5 is a structural block diagram of an optional driver program cross-platform transplantation device according to an embodiment of the present application, such as Figure 5 As shown, the device may include:

[0106] The code acquisition module 501 is used to acquire a group of first source driver blocks and a group of second source driver blocks corresponding to the source driver code of the source platform; the source driver code is divided into a plurality of source driver blocks, a group of first source driver blocks are code blocks that do not allow direct cross-platform transplantation, and a group of second source driver blocks are code blocks that allow direct cross-platform transplantation;

[0107] A migration rule module 502 is used to obtain a migration rule table of each first source driver block in a group of first source driver blocks, and modify each first source driver block according to the migration rule table of each first source driver block to obtain a modified group of first source driver blocks;

[0108] The code generation module 503 is used to generate target driver code based on the modified set of first source driver blocks and the modified set of second source driver blocks, and deploy the target driver code to the target platform.

[0109] In an exemplary embodiment, each of the multiple source driver blocks corresponds to first semantic data; the first semantic data corresponding to each source driver block is used to describe the meaning of the elements in each source driver block; the code acquisition module 501 is also used to match the first semantic data corresponding to each source driver block with multiple second semantic data stored in a pre-established source driver block semantic library; each of the multiple second semantic data is used to describe information in the source driver program code that does not allow direct cross-platform porting; among the multiple source driver blocks, the source driver blocks whose corresponding first semantic data have matching second semantic data are determined as first source driver blocks to obtain a group of first source driver blocks; among the multiple source driver blocks, the source driver blocks whose corresponding first semantic data do not have matching second semantic data are determined as second source driver blocks to obtain a group of second source driver blocks.

[0110] In an exemplary embodiment, the transplantation rule module 502 is also used to search for a transplantation rule table corresponding to each first source driver block from multiple transplantation rule tables stored in a pre-established transplantation rule library according to the first semantic data corresponding to each first source driver block; each transplantation rule table in the multiple transplantation rule tables is used to describe the rules for transplanting a code block to the target platform.

[0111] In an exemplary embodiment, the transplantation rule module 502 is also used to generate a prompt word corresponding to each first source driver block according to each first source driver block and the transplantation rule table of each first source driver block; the prompt word corresponding to each first source driver block is used to prompt the method of transplanting each first source driver block; by calling the model interface of the pre-trained large language model, each first source driver block is modified according to the prompt word corresponding to each first source driver block to obtain a modified set of first source driver blocks.

[0112] In an exemplary embodiment, the transplantation rule module 502 is also used to perform the following filling operations on each first source driver block as the current first source driver block to obtain a prompt word corresponding to each first source driver block: obtain a pre-established prompt word template; the prompt word template includes a code area and a transplantation rule area; fill the current first source driver block into the code area in the prompt word template, and fill the transplantation rule table of the current first source driver block into the transplantation rule area in the prompt word template to obtain a filled prompt word template; generate a prompt word corresponding to the current first source driver block according to the content of the filled prompt word template.

[0113] In an exemplary embodiment, the code generation module 503 is also used to build a cross-compilation environment corresponding to the target platform based on the software and hardware information of the target platform; in the cross-compilation environment, pre-built test cases are used to test the target driver code to obtain code test results; and the target driver code is adjusted according to the code test results so that the target driver code can run normally on the target platform.

[0114] In an exemplary embodiment, the code generation module 503 is also used to perform a quality assessment on the adjusted target driver code based on preset indicators to obtain a quality assessment result; when the quality assessment result indicates that the target driver code is at risk, the target driver code is adjusted, and the quality of the adjusted target driver code is re-evaluated until the re-evaluated quality assessment result indicates that the target driver code is safe, and triggers the step of deploying the target driver code to the target platform.

[0115] It should be noted that the examples and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the contents disclosed in the above embodiments. It should be noted that the above modules as part of the device can be run in Figure 1 In the hardware environment shown, it can be implemented by software or by hardware, wherein the hardware environment includes a network environment.

[0116] According to another aspect of the embodiments of the present application, a storage medium is further provided. Optionally, in this embodiment, the storage medium can be used to execute the program code of any of the above-mentioned driver program cross-platform transplantation methods in the embodiments of the present application.

[0117] Optionally, in this embodiment, the storage medium may be located on at least one network device among a plurality of network devices in the network shown in the above embodiment.

[0118] Optionally, in this embodiment, the storage medium is configured to store program codes for executing any of the above-mentioned driver program cross-platform transplantation methods.

[0119] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments, which will not be described in detail in this embodiment.

[0120] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media that can store program codes, such as a USB flash drive, a ROM, a RAM, a mobile hard disk, a magnetic disk, or an optical disk.

[0121] According to another aspect of the embodiments of the present application, an electronic device for implementing the above-mentioned driver cross-platform transplantation method is also provided. The electronic device may be a smart device, a server, a terminal, or a combination thereof.

[0122] Figure 6 is a structural block diagram of an optional electronic device according to an embodiment of the present application, such as Figure 6 As shown, it includes a processor 602, a communication interface 604, a memory 606 and a communication bus 608, wherein the processor 602, the communication interface 604 and the memory 606 communicate with each other through the communication bus 608, wherein,

[0123] Memory 606, used to store computer programs;

[0124] The processor 602 is used to implement the program code of any of the above-mentioned driver program cross-platform transplantation methods when executing the computer program stored in the memory 606.

[0125] Optionally, the communication bus may be a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The communication bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 The communication interface is used for communication between the above electronic device and other devices.

[0126] The memory may include RAM, or may include non-volatile memory, such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0127] As an example, the memory 606 may include but is not limited to the modules in the device for cross-platform migration of the driver program. In addition, it may also include but is not limited to other module units in the device for cross-platform migration of the driver program, which will not be described in detail in this example.

[0128] The above-mentioned processor can be a general-purpose processor, which can include but not be limited to: CPU (Central Processing Unit), NP (Network Processor), etc.; it can also be DSP (Digital Signal Processing), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0129] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments, and this embodiment will not be described in detail here.

[0130] It can be understood by those skilled in the art that Figure 6 The structure shown is for illustration only. The device for implementing the above-mentioned driver cross-platform transplantation method may be a terminal device, which may be a smart phone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile Internet device (Mobile Internet Devices, MID), a PAD, and other terminal devices. Figure 6The structure of the electronic device is not limited. Figure 6 More or fewer components (such as network interfaces, display devices, etc.) shown in, or having Figure 6 Different configurations shown.

[0131] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any of the above method embodiments are implemented.

[0132] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above method embodiments are implemented.

[0133] The embodiments of the present application also provide a computer program, which includes computer instructions, which are stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the steps in any one of the above method embodiments.

[0134] A person of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the hardware related to the terminal device through a program, and the program can be stored in a computer-readable storage medium, which can include: a flash drive, ROM, RAM, a magnetic disk or an optical disk, etc.

[0135] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0136] If the integrated units in the above embodiments are implemented in the form of software functional units and sold or used as independent products, they can be stored in the above computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application.

[0137] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0138] In the several embodiments provided in the present application, it should be understood that the disclosed client can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. 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 mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

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

[0140] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, each unit may exist physically separately, or at least two units may be integrated into one unit. The above integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0141] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for cross-platform migration of a driver, characterized in that: include: Acquire a set of first source driver blocks and a set of second source driver blocks corresponding to the source driver code of the source platform; The source driver code is divided into a plurality of source driver blocks, the first group of source driver blocks are code blocks that do not allow direct cross-platform transplantation, and the second group of source driver blocks are code blocks that allow direct cross-platform transplantation; Acquire a migration rule table of each first source driver block in the group of first source driver blocks, and modify each first source driver block according to the migration rule table of each first source driver block to obtain a modified group of first source driver blocks; Based on the modified set of first source driver blocks and the set of second source driver blocks, a target driver code is generated, and the target driver code is deployed to a target platform.

2. The method according to claim 1, characterized in that: Each of the plurality of source driver blocks corresponds to first semantic data; the first semantic data corresponding to each source driver block is used to describe the meaning of the elements in each source driver block; The step of obtaining a group of first source driver blocks and a group of second source driver blocks corresponding to the source driver code of the source platform includes: Matching the first semantic data corresponding to each source driver block with a plurality of second semantic data stored in a pre-established source driver block semantic library; each second semantic data in the plurality of second semantic data is used to describe information in the source driver code that is not allowed to be directly transplanted across platforms; Determine, among the plurality of source driver blocks, source driver blocks whose corresponding first semantic data have matching second semantic data as first source driver blocks, to obtain a group of first source driver blocks; Among the plurality of source driver blocks, source driver blocks whose corresponding first semantic data do not have matching second semantic data are determined as second source driver blocks to obtain a group of second source driver blocks.

3. The method according to claim 1, characterized in that Each of the plurality of source driver blocks corresponds to first semantic data; the first semantic data corresponding to each source driver block is used to describe the meaning of the elements in each source driver block; The step of obtaining the migration rule table of each first source driver block in the group of first source driver blocks comprises: According to the first semantic data corresponding to each first source driver block, a transplantation rule table corresponding to each first source driver block is searched from multiple transplantation rule tables stored in a pre-established transplantation rule library; each transplantation rule table in the multiple transplantation rule tables is used to describe the rules for transplanting a code block to the target platform.

4. The method according to claim 1, characterized in that The step of modifying each first source driver block according to the migration rule table of each first source driver block to obtain the modified group of first source driver blocks includes: According to each of the first source driver blocks and the transplantation rule table of each of the first source driver blocks, a prompt word corresponding to each of the first source driver blocks is generated; the prompt word corresponding to each of the first source driver blocks is used to prompt a method for transplanting each of the first source driver blocks; By calling the model interface of the pre-trained large language model, each of the first source driver blocks is modified according to the prompt words corresponding to each of the first source driver blocks to obtain the modified group of first source driver blocks.

5. The method according to claim 4, characterized in that The step of generating a prompt word corresponding to each first source driver block according to each first source driver block and a migration rule table of each first source driver block includes: Take each of the first source driver blocks as the current first source driver block and perform the following filling operation to obtain a prompt word corresponding to each of the first source driver blocks: Acquire a pre-established prompt word template; the prompt word template includes a code area and a transplant rule area; Filling the current first source driver block into the code area in the prompt word template, and filling the migration rule table of the current first source driver block into the migration rule area in the prompt word template, to obtain the filled prompt word template; According to the content of the filled prompt word template, a prompt word corresponding to the current first source driver block is generated.

6. The method according to any one of claims 1 to 5, characterized in that Before deploying the target driver code to the target platform, the method further includes: Constructing a cross-compilation environment corresponding to the target platform according to the software and hardware information of the target platform; In the cross-compilation environment, using pre-built test cases to test the target driver code and obtain code test results; The target driver code is adjusted according to the code test result, so that the target driver code can run normally on the target platform.

7. The method according to claim 6, characterized in that The method further comprises: Based on preset indicators, quality assessment is performed on the adjusted target driver code to obtain a quality assessment result; In the case where the quality assessment result indicates that there is a risk in the target driver code, the target driver code is adjusted, and the adjusted target driver code is re-evaluated in quality until the re-evaluated quality assessment result indicates that the target driver code is safe, and triggers the step of deploying the target driver code to the target platform.

8. A cross-platform driver transplantation device, characterized in that: include: A code acquisition module, used for acquiring a group of first source driver blocks and a group of second source driver blocks corresponding to the source driver code of the source platform; The source driver code is divided into a plurality of source driver blocks, the first group of source driver blocks are code blocks that do not allow direct cross-platform transplantation, and the second group of source driver blocks are code blocks that allow direct cross-platform transplantation; A transplantation rule module, used for obtaining a transplantation rule table of each first source driver block in the group of first source driver blocks, and modifying each first source driver block according to the transplantation rule table of each first source driver block to obtain a modified group of first source driver blocks; A code generation module is used to generate a target driver code based on the modified set of first source driver blocks and the set of second source driver blocks, and deploy the target driver code to a target platform.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program implements the steps of any one of the methods of claims 1 to 7 when executed by a processor.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

Images