Patch making method of multi-level system, patch method and program product

Abstract

The embodiment of the invention provides a patch making method of a multi-level system, a patch method and a program product. The multi-level system comprises an upper-layer system and a bottom-layer system, the upper-layer system is generated by performing function modification, function deletion or function addition on the bottom-layer system, and the operation of the upper-layer system is supported by the bottom-layer system; the method comprises the following steps: determining a to-be-patched module in a system; obtaining a patch merging rule, and generating a rule description file; the patch merging rule is used for indicating a processing rule when patch conflicts occur in different hierarchical systems; generating a patch file based on the patch merging rule and the patch source code, and compiling the patch file to obtain a patch script; and storing the to-be-patched module. Through the method, a developer only needs to formulate the patch merging rule, and does not need to manually modify conflict parts or conflict codes in the two patch files, so that the conflict solving efficiency and accuracy are improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a patch production method, a patch method, and a program product for a multi-level system. Background Art

[0002] In modern software development, systems often consist of multiple layers. During the development process, both underlying and upper-layer systems may require upgrades or patches, which is where patches are applied. However, after patch 1 is applied to the underlying system, applying patch 2 to the upper-layer system may cause a conflict with patch 1, leading to system instability or even crashes. Relevant technologies often require manual intervention to resolve patch conflicts, but this approach is inefficient and error-prone. Summary of the Invention

[0003] The purpose of the embodiments of the present application is to provide a patch production method, a patch method, and a program product for a multi-level system, so as to achieve the technical effect of resolving patch conflicts in systems at different levels.

[0004] In a first aspect, an embodiment of the present application provides a patch creation method for a multi-layer system, wherein the multi-layer system includes an upper-layer system and an underlying system, wherein the upper-layer system is generated by modifying, deleting, or adding functions to the underlying system, and the operation of the upper-layer system is supported by the underlying system; the method includes:

[0005] Determine a module to be patched in a system; the system includes the upper system and the bottom system;

[0006] Obtaining patch merging rules and generating a rule description file; wherein the patch merging rules are used to indicate the processing rules when patch conflicts occur in systems at different levels;

[0007] Generate a patch file based on the patch merging rule and the patch source code, and compile the patch file to obtain a patch script; wherein the patch source code is used to instruct patching the module to be patched;

[0008] A patch collection file of the module to be patched is stored, wherein the patch collection file includes the rule description file and the patch script.

[0009] In this implementation, patch merge rules are developed for the modules to be patched in both the upper and lower systems, and these rules are compiled into the patch script. These rules govern the handling of patch conflicts between the two layers, resolving patch conflicts between different layers within a multi-layered system. This approach allows developers to simply develop the patch merge rules, eliminating the need to manually modify conflicting sections of the two patch files or modify conflicting code. This improves conflict resolution efficiency and accuracy.

[0010] Furthermore, the method further comprises:

[0011] A specification file for a patch file is obtained, where the specification file is used to indicate a format specification and a naming specification of the patch file; the patch set file also includes the specification file.

[0012] In the above implementation process, the stored patch set file includes the specification file, the rule description file and the patch script, so that developers can subsequently view the specification requirements of the patch file from the specification file.

[0013] A second aspect of an embodiment of the present application provides a patch method for a multi-layer system, wherein the multi-layer system includes an upper-layer system and an underlying system, wherein the upper-layer system is generated by modifying, deleting, or adding functions to the underlying system, and the operation of the upper-layer system is supported by the underlying system; the method includes:

[0014] In response to a patch instruction for a module to be patched, determining a patch script for the module to be patched; wherein the patch script is obtained by compiling a patch file, the patch file including patch source code for instructing the module to be patched and patch merging rules, the patch merging rules being used to indicate a handling rule for patch conflicts occurring in systems at different levels;

[0015] In the process of compiling the source code of the module to be patched, calling the patch script and executing the patch script to obtain a modified source code;

[0016] The modified source code is compiled to obtain a version file of the module to be patched.

[0017] In the above implementation process, the patch script is called during the patch process of the patch module. Since the patch script indicates the process of modifying the source code of the patch module from the original version to the updated version, and includes the binary language corresponding to the patch merge rule, and the patch merge rule guides how to deal with the patch conflict between the two-level systems, the patch module can be patched when the patch script is run. At the same time, the patch process is constrained by the patch merge rule, so the problem of patch conflict between different level systems in the multi-level system can be solved.

[0018] Furthermore, determining the patch script of the module to be patched includes:

[0019] Obtain a patch set file of the module to be patched, the patch set file including the patch script, a rule description file of the patch merging rule, and a specification file for the patch file; the specification file is used to indicate the format specification and naming specification of the patch file.

[0020] In the above implementation process, the patch script of the module to be patched is obtained through the pre-established patch collection file. The patch collection file also records the specification file of the patch file and the rule description file of the patch merging rules, which makes it convenient for developers to view the regulations and rules set for the patch module.

[0021] Furthermore, before executing the patch script, the method further includes:

[0022] Obtaining the patch file;

[0023] Parsing the specification file in the patch collection file;

[0024] The patch file is checked to comply with the format specification and naming specification indicated in the specification file.

[0025] In the above implementation process, the patch file is first checked for compliance before the patch script is executed, which can ensure that subsequent patch conflicts are successfully resolved.

[0026] Furthermore, calling the patch script includes:

[0027] The patch script is called through a hook function preset in the compilation process.

[0028] In the above implementation process, by presetting the hook function in the compilation process, the patch script can be flexibly called in the compilation process to perform patching.

[0029] Furthermore, the patch merging rules include one or more of the following:

[0030] If the patch files corresponding to the two systems indicate that the same part of the same file in the module to be patched should be modified, the modification is performed based on the patch file with the highest version number; the version number is determined based on the name of the patch file;

[0031] If the patch files corresponding to the two systems indicate that different parts of the same file in the module to be patched should be modified, the modifications are performed based on the patch files corresponding to the two systems respectively;

[0032] If the patch files corresponding to the two systems indicate that the same part of the same file in the module to be patched should be deleted, the deletion operation of any one patch file is retained and the deletion operation of the other patch file is deleted;

[0033] If the patch files corresponding to the two systems indicate conflicting modifications to the same file in the patch module, the target patch file is determined according to a predefined priority rule and the modification is performed based on the target patch file; the priority rule includes a time priority rule or a version priority rule.

[0034] In the above implementation process, by formulating different patch merging rules, patch conflict problems in various scenarios can be effectively resolved.

[0035] A third aspect of the embodiments of the present application provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements the method described in either the first aspect or the second aspect.

[0036] A fourth aspect of the embodiments of the present application provides an electronic device, comprising:

[0037] processor;

[0038] a memory for storing processor-executable instructions;

[0039] Wherein, when the processor calls the executable instruction, it implements the operation of any method described in the first aspect or the second aspect.

[0040] A fifth aspect of an embodiment of the present application provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of any of the methods described in the first aspect or the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without creative work.

[0042] Figure 1 A flowchart of a patch production method for a multi-level system provided in an embodiment of the present application;

[0043] Figure 2 A schematic diagram of a multi-level system patching method provided in an embodiment of the present application;

[0044] Figure 3 A flowchart of another multi-level system patching method provided in an embodiment of the present application;

[0045] Figure 4 A hardware structure diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0046] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0047] It should be noted that similar reference numerals and letters represent similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and should not be understood as indicating or implying relative importance.

[0048] The multi-layer system includes an upper-layer system and a bottom-layer system. Among them, the upper-layer system may include one or more, and the bottom-layer system may include one or more. The multi-layer system described in this application is not limited to a two-layer system, and may also be a three-layer system, a four-layer system, etc. The upper-layer system is generated by modifying, deleting or adding functions to the bottom-layer system, and the operation of the upper-layer system is supported by the bottom-layer system. For example, the tools and resources provided by the SDK (Software Development Kit) can be used to build an extensible platform architecture that supports modular function expansion. The system carried by the platform architecture is the bottom-layer system, and the system obtained after modular function expansion based on the platform architecture is the upper-layer system. The modular function expansion includes the modification of function modules, the deletion of function modules or the addition of function modules.

[0049] It should be distinguished that the multi-level system described in this application is different from the software architecture model of the system in the related art. The software architecture model of the system includes a three-tier architecture, that is, a system is divided into three levels: presentation layer, business logic layer and data access layer. The software architecture model of the system also includes a four-tier architecture, that is, a system is divided into four levels: client layer, presentation layer, business logic layer and data layer. It should be understood that the software architecture model of the system is an architecture that can be divided into three or four layers for a system. However, the multi-level system described in this application describes the relationship between multiple systems, that is, the upper-level system is generated by modifying, deleting or adding functions to the underlying system, and the operation of the upper-level system is supported by the underlying system. Therefore, it is different from the above-mentioned software architecture model.

[0050] In related technologies, when conflicts arise across multiple layers of systems, manual inspection and resolution are often required. For example, patch files from two layers of systems are merged to modify the conflicting parts of the two patch files. Another example is manually modifying the conflicting code in each system after the patch is applied. However, this approach is inefficient and prone to errors.

[0051] In order to solve the problem of patch conflicts in different hierarchical systems, the first aspect of the present application provides a patch production method for a multi-level system, which is applied to the multi-level system mentioned above. The method includes: Figure 1 Steps 110 to 140 are shown.

[0052] Step 110: Determine the module to be patched in the system; the system includes the upper system and the bottom system.

[0053] Exemplarily, the system of each level in the multi-level system is functionally modularized, that is, the system of each level includes multiple functional modules. When performing a system upgrade or patch, one or more functional modules in the system can be upgraded or patched. Specifically, the developer can pull the source code of the upper-level system and the source code of the underlying system respectively, and determine the module to be patched by analyzing the system source code. Determining the module to be patched in the system refers to determining the module to be patched in the upper-level system and the module to be patched in the underlying system respectively. The upper-level system and the underlying system can determine the same module to be patched, or different modules to be patched. For example, the upper-level system can determine module A to be patched and module B to be patched, and the underlying system can determine module B to be patched and module C to be patched. Although module A to be patched and module C to be patched are not the same functional module, corresponding patches can still be made according to the method provided in this embodiment. Therefore, each module to be patched determined from the upper-level system and the underlying system can be patched accordingly by this embodiment.

[0054] Step 120: Obtain patch merging rules and generate a rule description file; wherein the patch merging rules are used to indicate processing rules when patch conflicts occur in systems at different levels.

[0055] For example, patch merge rules can be formulated by developers, specifically patch merge rules formulated for the module to be patched. Patch merge rules for different modules to be patched may be the same or different. Obtaining the patch merge rules can involve obtaining patch merge rules input by the developer. A rule description file explains the patch merge rules for future review by the developer. Specific implementations of the patch merge rules are described below.

[0056] Step 130: Generate a patch file based on the patch merging rule and the patch source code, and compile the patch file to obtain a patch script; wherein the patch source code is used to instruct patching the module to be patched.

[0057] Exemplarily, a developer may write a patch source code, and the patch source code may indicate that a patch module is to be patched, that is, indicates the process of modifying the source code of the original version of the patch module to the source code of the updated version. A patch file is generated based on the patch merge rule and the patch source code, so that the patch file may include the source code corresponding to the patch merge rule and the patch source code. Subsequently, the patch file is compiled to compile the source code in the patch file into a binary language recognizable by a computer, thereby obtaining a patch script. It can be seen that the patch script carries the binary language corresponding to the patch merge rule and the binary language corresponding to the patch source code, so that the patch module can be patched when the patch script is run, and at the same time, the patch process is constrained by the patch merge rule.

[0058] Step 140: Store the patch collection file of the module to be patched, where the patch collection file includes the rule description file and the patch script.

[0059] For example, after obtaining the rule description file and patch script of the module to be patched, the rule description file and patch script can be stored as a patch collection file, and a mapping relationship can be established with the module to be patched, so that the patch collection file corresponding to each module to be patched can be found using the mapping relationship. In addition, the patch file corresponding to each module to be patched can also be stored.

[0060] This application provides a method for creating patches for a multi-layered system. By formulating patch merging rules for the modules to be patched in the upper and lower layers, and compiling these rules into the patch script, the patches for the modules to be patched are subject to the patch merging rules. The patch merging rules provide guidance on how to handle patch conflicts between the two layers, thus resolving patch conflicts between different layers within a multi-layered system. This method allows developers to simply formulate patch merging rules without having to manually modify the conflicting parts of the two patch files or modify the conflicting code, thereby improving the efficiency and accuracy of conflict resolution.

[0061] In some embodiments, the method further includes: obtaining a specification file for the patch file, the specification file being used to indicate a format specification and a naming specification for the patch file. Based on this, the patch collection file also includes the specification file.

[0062] For example, developers can implement specification requirements for patch files, such as establishing unified format specifications and naming specifications for patch files of each hierarchical system to ensure that all patch files meet the requirements. The specification requirements of different hierarchical systems can be the same or different. For example, the specification requirements may include that patch files must be in json format and the naming must include the name of the module to be patched, the version number, and the patch number. Based on this, the patch collection file stored in the above step 140 may include a specification file, a rule description file, and the patch script, so that developers can subsequently view the specification requirements of the patch files from the specification file.

[0063] Based on the patch making method provided in any of the above embodiments, the second aspect of the present application further provides a patching method for a multi-level system, for patching a module to be patched using the patch made in the first aspect. The patching method is applied to the multi-level system mentioned above, and the patching method includes: Figure 2 Steps 210 to 230 are shown.

[0064] Step 210: In response to the patch instruction for the module to be patched, determine the patch script of the module to be patched; wherein the patch script is obtained after compiling the patch file, and the patch file includes a patch source code for instructing the module to be patched and a patch merging rule, and the patch merging rule is used to indicate the processing rules when patch conflicts occur in systems at different levels.

[0065] Exemplarily, the patch instruction can be generated by the system or input by a developer. When a patch instruction for a module to be patched is received, the patch script for the module to be patched is first determined, for example, by obtaining a pre-stored patch script for the module to be patched. The module to be patched can be a functional module included in both the upper-layer system and the underlying system. When patching a functional module included in both the upper-layer system and the underlying system, if the upper-layer system and the underlying system perform different operations on the functional module (i.e., the module to be patched), a patch conflict may occur. The patch script is obtained by compiling a patch file, and the patch file includes the patch source code and the source code of the patch merge rules. The patch source code is used to instruct the module to be patched to be patched, that is, to indicate the process of modifying the source code of the module to be patched from the original version to the updated version. The patch merge rules are used to indicate the handling rules when patch conflicts occur in systems at different levels. Since the patch script is compiled from the patch file, the patch script carries the binary language corresponding to the patch merge rules and the binary language corresponding to the patch source code, so that the module to be patched can be patched when the patch script is run, and the patch process is also constrained by the patch merge rules.

[0066] Step 220: During the process of compiling the source code of the module to be patched, the patch script is called and executed to obtain the modified source code.

[0067] For example, during the patching process of the module to be patched, the compilation process can be first entered through the compilation framework entry. Subsequently, during the compilation of the source code of the module to be patched, the patch script of the module to be patched is called and executed. Because the patch script indicates the process of modifying the source code of the module to be patched from the original version to the updated version, the modified source code of the module to be patched can be obtained after executing the patch script.

[0068] Step 230: Compile the modified source code to obtain a version file of the module to be patched.

[0069] For example, after obtaining the modified source code, it can be compiled to obtain a version file of the module to be patched. By running the version file, the updated functional module can be obtained.

[0070] In some embodiments, makefile can be used as a compilation attack, and a makefile file can be written in each patch directory. The corresponding patch script can be called through the makefile file, and each patch script can be specified to be executed during the patch validation phase.

[0071] It can be seen that the present application provides a patch method for a multi-level system, which calls a patch script during the patch process of the patch module. Since the patch script indicates the process of modifying the source code of the module to be patched from the original version to the source code of the updated version, and includes the binary language corresponding to the patch merge rules, and the patch merge rules guide how to deal with patch conflicts between the two-level systems, the patch module can be patched when the patch script is run, and the patch process is constrained by the patch merge rules. Therefore, the problem of patch conflicts between different level systems in the multi-level system can be solved.

[0072] In some embodiments, determining the patch script of the module to be patched in step 210 specifically includes step 211 .

[0073] Step 211: Obtain the patch set file of the module to be patched, the patch set file including the patch script, the rule description file of the patch merging rule, and the specification file for the patch file; the specification file is used to indicate the format specification and naming specification of the patch file.

[0074] As described above in the multi-level system patch creation method provided in the first aspect, after obtaining the rule description file, patch script, and specification file for the module to be patched, the rule description file, patch script, and specification file can be stored as a patch collection file and a mapping relationship can be established between the module to be patched. Based on this, when executing step 211, the mapping relationship can be used to find the patch collection file corresponding to the module to be patched, and the patch script can be obtained from the patch collection file.

[0075] It can be seen that in this embodiment, the patch script of the module to be patched is obtained through the pre-established patch collection file. The patch collection file also records the specification file of the patch file and the rule description file of the patch merging rules, which makes it convenient for developers to view the regulations and rules set for the patch module.

[0076] According to some embodiments of the present application, based on step 211, before executing the patch script, the method further includes: Figure 3 Steps 310 to 330 are shown.

[0077] Step 310: Obtain the patch file.

[0078] For example, a patch file pre-stored in the module to be patched may be obtained, wherein the patch file records the source code of the patch and the source code of the patch merging rule.

[0079] Step 320: Parse the specification file in the patch collection file.

[0080] Illustratively, a patch set file of the module to be patched is obtained in step 211. Since the patch set file also includes a specification file for the patch file, the specification file can be obtained and parsed to obtain specification requirements for the patch file, including format specifications and naming specifications.

[0081] Step 330: Check that the patch file complies with the format specification and naming specification indicated in the specification file.

[0082] Exemplarily, before executing the patch script, first check whether the patch file complies with the format specifications and naming specifications indicated in the specification file. If it is determined that the patch file complies with the specifications, then execute the patch script compiled by the patch file, otherwise you may choose not to execute the patch script. This is because when a patch conflict occurs, it may be necessary to determine the priority between each patch file based on the naming of the patch file. The naming specification specifies the naming rules for patch files of different priorities. If the patch file does not meet the specification requirements, it may lead to the inability to distinguish the priority between the patches from the naming of the files when a patch conflict occurs later, resulting in the failure of conflict resolution. Therefore, performing a specification check on the patch file before executing the patch script can ensure that subsequent patch conflicts are successfully resolved.

[0083] In addition, based on any of the above embodiments, the calling of the patch script in step 220 may specifically include:

[0084] The patch script is called through a hook function preset in the compilation process.

[0085] Exemplarily, the compilation process can include a pre-embedded hook function. During the compilation process, the hook function can be used to call and execute the patch script. Optionally, if the hook function call fails, the compilation process is terminated. If the patch script execution fails, the exception information is returned to the compilation tool, and the patch script is called again through the hook function. It can be seen that by pre-setting the hook function in the compilation process, the patch script can be flexibly called in the compilation process to perform patching.

[0086] In addition, based on any of the above embodiments, the patch merging rules include one or more of the following:

[0087] Rule 1: If the patch files corresponding to two systems indicate that the same part of the same file in the module to be patched should be modified, the modification is performed based on the patch file with the highest version number; the version number is determined based on the name of the patch file.

[0088] That is, when the patch files of the upper-level system and the lower-level system both indicate the modification of the same part of the same file in the module to be patched, since the naming convention of the patch file is indicated in the specification file of the patch file, and the naming convention specifies the naming rules of patch files of different priorities, the patch file with the highest version number can be determined through the naming of the patch files corresponding to the two hierarchical systems, and the file can be patched based on the patch file with the highest version number, thereby solving the problem of patch conflict for the same part of the same file.

[0089] Rule 2: If the patch files corresponding to the two systems indicate that different parts of the same file in the module to be patched should be modified, the modifications are performed based on the patch files corresponding to the two systems respectively.

[0090] That is, when the patch files of the upper system and the lower system instruct to modify different parts of the same file in the module to be patched, no patch conflict will occur, so the modifications can be performed based on the two patch files respectively.

[0091] Rule 3: If the patch files corresponding to two systems instruct to delete the same part of the same file in the module to be patched, the deletion operation of either patch file is retained and the deletion operation of the other patch file is deleted.

[0092] Specifically, if both the upper-layer and lower-layer patch files specify deleting the same portion of the same file in the module to be patched, executing the deletion operation according to one system's patch file will cause the deletion target to not exist when executing the deletion operation according to the other system's patch file, as that portion has already been deleted. This will result in a patch error. Therefore, Rule 3 specifies that only the deletion operation of one patch file is retained, while the deletion operation of the other patch file is deleted, thus avoiding patch errors caused by the deletion target not existing.

[0093] Rule 4: If the patch files corresponding to the two systems indicate conflicting modifications to the same file in the patch module, the target patch file is determined according to a predefined priority rule and the modification is performed based on the target patch file; the priority rule includes a time priority rule or a version priority rule.

[0094] That is, when the patch files of the upper system and the underlying system both indicate that conflicting modifications should be made to the same file in the patch module, the target patch file with the highest priority is determined from the two patch files according to the predefined priority rules. Then the patch module is patched based on the target patch file. Among them, the priority rule can be a time priority rule, for example, the priority of the patch file generated earlier is higher than the priority of the patch file generated later, or the priority of the patch file generated earlier is lower than the priority of the patch file generated later. The priority rule can be a version priority rule, that is, the priority of the patch file with a higher version is higher than the priority of the patch file with a lower version. In this way, the target patch file with the highest priority is determined based on the priority rule, and the module to be patched is modified only according to the target patch file, and patch files of other priorities are ignored, thereby solving the problem of patch conflicts caused by patch files of different priorities.

[0095] It can be seen that this embodiment can effectively solve patch conflict problems in various scenarios by formulating different patch merging rules.

[0096] In order to better understand this solution, the following example is used to further illustrate it.

[0097] A company developed business system B based on platform system A. Business system B's operation is supported by platform system A, with platform system A serving as the underlying system and business system B as the upper-level system. In both platform system A and business system B, process P is controlled by the startup script init.sh. In platform system A, process P is set to automatically start at startup. During a patching operation, both platform system A and business system B need to patch process P in the init module.

[0098] During patch development, developers first establish specifications for the patch file for the init module. Specifically, they can require that patch files be in JSON format, named "module name_version number_patch name." For example, a patch file for the init module might be named "init_v1.0_patch001.json," indicating that this is patch file numbered 001 for the init module. Subsequently, patch merging rules can be established, such as Rules 1 through 4 described in the previous example.

[0099] During its iteration, platform system A discovered that process P was not universally applicable. The plan was to remove process P's startup functionality from the init module. During its iteration, business system B discovered that process P had diverse user groups and performance requirements. While retaining process P, the plan was to determine the number of cores bound to process P according to device rules. This resulted in a patch conflict between platform system A and business system B in the init module, specifically in process P.

[0100] Based on this, the patch collection file created by platform system A includes the patch file init_v1.0_patch001.json. The patch merging rule used may include "abandon the current patch if it conflicts with other patches." The pseudo code of the specific patch script is:

[0101] if(other_patch_module_name==init&&update_content==process P){

[0102] / / Delete the current patch point

[0103] / / quit

[0104] }else{

[0105] / / Delete the startup command of process P from init.sh

[0106] }

[0107] The patch collection file created by business system B includes the patch file init_v1.0_patch002.json. The patch merging rule used may include "wait until other patch scripts are executed before executing the current patch script." The pseudo code of the specific patch script is:

[0108] if(other_patch_module_name==init&&update_content==process P){

[0109] / / Traverse the patch points that meet the filter and execute the scripts in each patch point in turn

[0110] }

[0111] / / Determine the number of cores based on the configuration and overwrite the startup command.

[0112] It can be seen that by using patch merging rules to guide how to deal with patch conflicts in the two-tier systems, when the patch script of the running platform system A finds a patch conflict, it abandons the operation of deleting the patch started by process P at startup, solving the problem of patch conflict with business system B in the init module.

[0113] Based on the multi-layer system patching method and multi-layer system patching method described in any of the above embodiments, the present application also provides a computer program product, which includes one or more computer programs or instructions. The computer programs or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another computer-readable storage medium. When executed by a processor, the computer program implements the multi-layer system patching method and multi-layer system patching method described in any of the above embodiments.

[0114] Based on the patch making method of a multi-level system and the patch method of a multi-level system described in any of the above embodiments, the present application also provides the following Figure 4 A schematic diagram of the structure of an electronic device is shown in FIG. Figure 4 At the hardware level, the electronic device includes a processor, an internal bus, a network interface, memory, and non-volatile storage, and may also include other hardware required for its operations. The processor reads the corresponding computer program from the non-volatile storage into the internal memory and then runs it to implement the multi-level system patching method and multi-level system patching method described in any of the above embodiments.

[0115] The present application also provides a computer storage medium storing a computer program. When the computer program is executed by a processor, it can be used to execute a multi-level system patch production method and a multi-level system patch method described in any of the above embodiments.

[0116] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architectures, functions and operations of the devices, methods and computer program products according to the multiple embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of the code, and the module, program segment or a part of the code contains one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or can be implemented using a combination of dedicated hardware and computer instructions.

[0117] In addition, the functional modules in each embodiment of the present application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0118] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a 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 the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0119] The foregoing is merely an embodiment of the present application and is not intended to limit the scope of protection of the present application. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included within the scope of protection of the present application. It should be noted that similar reference numerals and letters represent similar items in the following figures. Therefore, once an item is defined in one figure, it does not need to be further defined or explained in subsequent figures.

[0120] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

[0121] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply the existence of any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.

Claims

1. A patch production method for a multi-level system, characterized in that: The multi-layer system includes an upper system and an underlying system. The upper system is generated by modifying, deleting, or adding functions to the underlying system. The operation of the upper system is supported by the underlying system. The method includes: Determine a module to be patched in a system; the system includes the upper system and the bottom system; Obtaining patch merging rules and generating a rule description file; wherein the patch merging rules are used to indicate the processing rules when patch conflicts occur in systems at different levels; Generate a patch file based on the patch merging rule and the patch source code, and compile the patch file to obtain a patch script; wherein the patch source code is used to instruct patching the module to be patched; A patch collection file of the module to be patched is stored, wherein the patch collection file includes the rule description file and the patch script.

2. The method according to claim 1, characterized in that The method further comprises: A specification file for a patch file is obtained, where the specification file is used to indicate a format specification and a naming specification of the patch file; the patch set file also includes the specification file.

3. A patching method for a multi-level system, characterized in that: The multi-layer system includes an upper system and an underlying system. The upper system is generated by modifying, deleting, or adding functions to the underlying system. The operation of the upper system is supported by the underlying system. The method includes: In response to a patch instruction for a module to be patched, determining a patch script for the module to be patched; wherein the patch script is obtained by compiling a patch file, the patch file including patch source code for instructing the module to be patched and patch merging rules, the patch merging rules being used to indicate a handling rule for patch conflicts occurring in systems at different levels; In the process of compiling the source code of the module to be patched, calling the patch script and executing the patch script to obtain a modified source code; The modified source code is compiled to obtain a version file of the module to be patched.

4. The method according to claim 3, characterized in that The step of determining the patch script for the module to be patched includes: Obtain a patch set file of the module to be patched, the patch set file including the patch script, a rule description file of the patch merging rule, and a specification file for the patch file; the specification file is used to indicate the format specification and naming specification of the patch file.

5. The method according to claim 4, characterized in that Before executing the patch script, the method further includes: Obtaining the patch file; Parsing the specification file in the patch collection file; The patch file is checked to comply with the format specification and naming specification indicated in the specification file.

6. The method according to claim 3, characterized in that The calling of the patch script includes: The patch script is called through a hook function preset in the compilation process.

7. The method according to any one of claims 3 to 6, characterized in that: The patch merging rules include one or more of the following: If the patch files corresponding to the two systems indicate that the same part of the same file in the module to be patched should be modified, the modification is performed based on the patch file with the highest version number; the version number is determined based on the name of the patch file; If the patch files corresponding to the two systems indicate that different parts of the same file in the module to be patched should be modified, the modifications are performed based on the patch files corresponding to the two systems respectively; If the patch files corresponding to the two systems indicate that the same part of the same file in the module to be patched should be deleted, the deletion operation of any one patch file is retained and the deletion operation of the other patch file is deleted; If the patch files corresponding to the two systems indicate conflicting modifications to the same file in the patch module, the target patch file is determined according to a predefined priority rule and the modification is performed based on the target patch file; the priority rule includes a time priority rule or a version priority rule.

8. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

9. An electronic device, characterized in that: The electronic device comprises: processor; a memory for storing processor-executable instructions; Wherein, when the processor calls the executable instruction, the operation of the method according to any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium, characterized in that Computer instructions are stored thereon, and when the computer instructions are executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images