Software patch upgrading method and device, equipment and storage medium

Abstract

The invention discloses a software patch upgrading method and device, equipment and a storage medium. The method comprises the steps of receiving an upgrading instruction, and obtaining a patch file package of a new version; calling an inspection function in the patch file package, and traversing all subdirectories in the patch file package to obtain a patch deliverable directory; acquiring a changed target patch deliverable from the patch file package under the condition that the deliverable in the patch deliverable directory is changed; and upgrading based on the target patch deliverable. According to the scheme provided by the embodiment of the invention, when the patch upgrading instruction is received, the patch file package can be analyzed, the changed patch delivery piece is identified, and only the changed part is subjected to incremental upgrading. And the unmodified deliverables are not subjected to repeated unloading and reloading actions. And the known problem that the original patch is triggered to be solved due to the neutral period without the patch in place in the patch upgrading process is reduced. Therefore, the reliability, usability and safety of the patch are greatly improved.

Description

Technical Field

[0001] The present application relates to the field of computer software technology, and in particular to a software patch upgrade method, device, equipment and storage medium. Background Art

[0002] With the rapid development of network technology, the demand for flexibility and high quality of network equipment is increasing, and higher requirements are placed on rapid response to demand and timely repair of faults. However, restarting and upgrading network equipment versions has always been a complex and difficult process. Therefore, the contradiction between customers' high-quality requirements for network equipment and the difficulty of improvement has become increasingly prominent. In this context, patch technology, with its flexibility, high efficiency and the characteristics of no need for device-level restart, has become the most effective means to solve the difficulties of version upgrades and efficiently meet customer requirements. Therefore, it has been widely used in the current network environment. However, the existing patch upgrade technology has some significant defects, which affect the efficiency and reliability of patch management.

[0003] First, in the existing patch upgrade process, some patches are only partially modified, and the unmodified deliverables are uninstalled and installed invalidly. This practice not only wastes system resources, but also increases the probability of errors during the upgrade process. Since the unmodified components are also involved in the uninstallation and reinstallation process, this may cause unnecessary system restarts, extend the maintenance window time, and reduce system availability. Secondly, when the patch is replaced and upgraded, there is a time gap between the uninstallation of the original patch and the installation of the new patch. During this period, the system may be in an unstable state, which is easy to trigger the known problems that have been solved by the original patch. The existence of this time gap makes the system face security risks during the upgrade process, especially when facing urgent security patches, this risk is more prominent. Summary of the invention

[0004] The embodiments of the present application provide a software patch upgrade method, apparatus, device and storage medium to at least solve the technical problem in the related art that it is difficult to perform incremental patch upgrades.

[0005] According to one aspect of an embodiment of the present application, a software patch upgrade method is provided, including:

[0006] Receive upgrade instructions and obtain the patch file package of the new version;

[0007] Calling the check function in the patch file package, traversing all subdirectories in the patch file package, and obtaining a patch delivery directory;

[0008] When a deliverable in the patch deliverable directory changes, obtaining the changed target patch deliverable from the patch file package;

[0009] An upgrade is performed based on the target patch deliverable.

[0010] In one implementation, performing an upgrade based on the target patch deliverable includes:

[0011] In the case where the target patch delivery is a cold patch, executing a first upgrade strategy; the first upgrade strategy includes a strategy for upgrading based on replacement and restart;

[0012] In the case where the target patch delivery is a hot patch, executing a second upgrade strategy; the second upgrade strategy includes an upgrade strategy based on function jump;

[0013] Among them, a cold patch is a patch that requires a device restart to run after installation, and a hot patch is a patch that does not require a device restart after installation.

[0014] In one implementation, when the target patch delivery is a cold patch, executing a first upgrade strategy includes:

[0015] In the case where the target patch deliverable is a patch deliverable in an old version that is modified, replacing the patch deliverable in the old version based on the target patch deliverable, and restarting the process;

[0016] In the case that the target patch delivery is a patch delivery of the old version with new content, the patch delivery of the base version is replaced based on the target patch delivery, and the process is restarted.

[0017] In one implementation, when the target patch deliverable is a hot patch, executing the second upgrade strategy includes:

[0018] In the case where the target patch delivery is a patch delivery in an old version that is modified, loading and running the target patch delivery in the file system; when detecting that the program runs to a first target function that needs to be modified, jumping from the first target function in the patch delivery in the old version to a second target function in the target patch delivery;

[0019] In the case that the target patch delivery is a patch delivery of the old version with newly added content, the target patch delivery is loaded and run in the file system; when it is detected that the program runs to the third target function that needs to be modified, the third target function in the patch delivery of the base version is jumped to the second target function in the target patch delivery.

[0020] In one embodiment, when the deliverable in the patch deliverable directory changes, before obtaining the changed target patch deliverable from the patch file package, the method further includes:

[0021] Parsing the patch file package to obtain a hash value of a configuration file of the patch delivery under the new version;

[0022] Get the hash value of the configuration file of the patch delivery under the old version in the system;

[0023] Generate a whitelist based on the hash values ​​of the configuration files in the new and old versions, where the whitelist contains patch deliverables that have not changed;

[0024] The patch deliverables that do not belong to the whitelist are obtained from the patch file package to obtain the changed target patch deliverables.

[0025] In one implementation, before parsing the patch file package, the method further includes:

[0026] A configuration patch file package, wherein a subdirectory of the patch file package includes a configuration file;

[0027] Calculating a hash value of the configuration file;

[0028] A hash value of the configuration file is added to the configuration file.

[0029] In one implementation, calculating the hash value of the configuration file and adding the hash value of the configuration file to the configuration file includes:

[0030] Traverse all subdirectories under the patch file package directory and identify the subdirectories to be calculated;

[0031] For each subdirectory to be calculated, construct a first configuration file, and copy the remaining contents of the original configuration file that do not contain the hash value entries to the first configuration file;

[0032] Initialize the hash value under the hash value entry in the original configuration file; construct a second configuration file, and copy all the contents in the original configuration file to the second configuration file;

[0033] Extracting the patch type and file name from the second configuration file, and constructing a patch delivery path for a patch delivery of a target type;

[0034] The patch delivery item content is queried based on the patch delivery item path, and a hash value of the patch delivery item is calculated. The hash value item string content is added to the first configuration file to obtain a configuration file containing the hash value.

[0035] According to another aspect of the embodiment of the present application, a software patch upgrade device is provided, including:

[0036] The acquisition module is used to receive the upgrade instruction and obtain the patch file package of the new version;

[0037] A check module, used to call a check function in the patch file package, traverse all subdirectories in the patch file package, and obtain a patch delivery directory;

[0038] A parsing module, configured to obtain a changed target patch deliverable from the patch file package when a deliverable in the patch deliverable directory changes;

[0039] An upgrade module is used to perform an upgrade based on the target patch deliverable.

[0040] According to another aspect of the embodiments of the present application, there is also provided an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the software patch upgrade method through the computer program.

[0041] 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 software patch upgrade method when running.

[0042] The technical solution provided by the embodiments of the present application may have the following beneficial effects:

[0043] The software patch upgrade solution provided in the embodiment of the present application can identify the changed patch deliverables from the patch file package when receiving the patch upgrade instruction, and only perform incremental upgrades on the changed parts. The deliverables that have not been modified are not repeatedly uninstalled and reloaded, and only the different deliverables in the two patches are uninstalled / installed. The operation of restarting the patch process during the installation process is reduced as much as possible, and the problem of time gaps in the patch replacement and upgrade process is effectively solved by performing incremental upgrades. Thereby greatly improving the reliability, ease of use and security of the patch, significantly reducing the probability of online problem triggering during the patch installation process, and improving customer satisfaction. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0045] Figure 1 is a schematic diagram of an application environment of the software patch upgrade method of an embodiment of the present application;

[0046] Figure 2 This is a schematic diagram of a process of upgrading a cold patch from a basic version to HS01 in an embodiment of the present application;

[0047] Figure 3 This is a schematic diagram of a process of upgrading a cold patch from HS01 to HS02 according to an embodiment of the present application;

[0048] Figure 4 This is a schematic diagram of a process of upgrading a cold patch from HS01 to HS02 according to an embodiment of the present application;

[0049] Figure 5 It is a schematic diagram of a process of upgrading a hot patch from a basic version to HS01 in an embodiment of the present application;

[0050] Figure 6 It is a schematic diagram of a process of upgrading a hot patch from HS01 to HS02 according to an embodiment of the present application;

[0051] Figure 7 It is a schematic diagram of a process of upgrading a hot patch from HS01 to HS02 according to an embodiment of the present application;

[0052] Figure 8 This is a schematic diagram of a process of upgrading a cold patch from HS01 to HS02 according to an embodiment of the present application;

[0053] Fig. 9 This is a schematic diagram of a process of upgrading a cold patch from HS01 to HS02 according to an embodiment of the present application;

[0054] Fig.10 It is a schematic diagram of a process of upgrading a hot patch from HS01 to HS02 according to an embodiment of the present application;

[0055] Fig.11 It is a schematic diagram of a process of upgrading a hot patch from HS01 to HS02 according to an embodiment of the present application;

[0056] Fig.12 A schematic diagram of a method for calculating a hash value of a patch delivery configuration file according to an embodiment of the present application;

[0057] Fig.13 A schematic diagram of the structure of a software patch upgrade device according to an embodiment of the present application;

[0058] Fig.14 The present invention is a schematic diagram of the structure of an optional electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0059] 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.

[0060] 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.

[0061] The following is combined with Figure 1-12 The software patch upgrade method of the embodiment of the present application is described in detail. It should be noted that the following application scenarios are only shown to facilitate understanding of the spirit and principle of the present application, and the implementation of the present application is not limited in this respect. On the contrary, the implementation of the present application can be applied to any applicable scenario. Figure 1 As shown, the method mainly includes the following steps:

[0062] S101 receives the upgrade instruction and obtains the patch file package of the new version.

[0063] The upgrade instruction is a command issued by the system administrator or automated tool to instruct the system to prepare and execute the software or firmware upgrade process. The patch file package includes multiple subdirectories, which contain a collection of all files and instructions required for software upgrades, usually including updated binary files, configuration files, scripts, and patch deliverables.

[0064] Specifically, the system receives the upgrade instruction through a network interface or a local management interface. This can be achieved through a command line tool, a web interface, or an automated management system. The upgrade instruction may include information such as the target version number, the location of the patch file package, and the upgrade strategy (such as immediate execution or scheduled execution). Based on the information provided in the upgrade instruction, the system downloads the patch file package from the specified server or storage location.

[0065] S102 calls the check function in the patch file package, traverses all subdirectories in the patch file package, and obtains the patch delivery directory.

[0066] In one implementation, the patch file package is parsed, and the patch file package includes a preset check function, which can traverse all subdirectories under the patch directory, identify the patch tool directory, remove the patch tools and non-folders, and obtain the patch delivery directory. When executing the upgrade method, the check function is called to traverse the patch file package.

[0067] S103: When a deliverable in the patch deliverable directory changes, obtain the changed target patch deliverable from the patch file package.

[0068] In one embodiment, when a deliverable in the patch deliverable directory changes, before obtaining the changed target patch deliverable from the patch file package, the method further includes:

[0069] Parse the patch file package to obtain the hash value of the configuration file of the patch delivery under the new version; obtain the hash value of the configuration file of the patch delivery under the old version in the system; generate a whitelist based on the hash values ​​of the configuration files under the new and old versions, and the whitelist contains the patch delivery items that have not changed; obtain the patch delivery items that are not on the whitelist from the patch file package, and obtain the target patch delivery items that have changed.

[0070] The embodiment of the present application determines whether the patch delivery has changed based on whether the hash values ​​of the configuration files of the patch delivery are consistent between the new and old versions. If the hash values ​​are consistent, it is determined that the patch delivery has not changed. If the hash values ​​are inconsistent, it is determined that the patch delivery has changed. The change may be to modify the historical delivery or to add new content based on the historical delivery.

[0071] The embodiment of the present application proposes a "whitelist" technology, which traverses the patch directory, identifies and records unchanged deliverables, adds unchanged deliverables to the whitelist, and only upgrades patch deliverables outside the whitelist.

[0072] In one embodiment, before parsing the patch file package, the patch file package is further configured, wherein the subdirectory of the patch file package includes a configuration file, a hash value of the configuration file is calculated, and the hash value of the configuration file is added to the configuration file.

[0073] It is understandable that when the incremental patch packaging is customized, it is necessary to ensure that each module patch subdirectory contains the configuration file patch.cfg, and the patch deliverable customized by file_name in the configuration file patch.cfg exists in the directory.

[0074] The patch.cfg configuration file includes:

[0075] patch_type:user_hot-----Define the patch type;

[0076] board_type:mpu_x86-----Defines the board type where the patch is installed;

[0077] file_name:libfwdplug_inetpatch_hs01.so------patch delivery;

[0078] source_file:

[0079] TARGET / user_release / mpu_x86_64 / lib / libfwdplug_inetpatch_hs01.so----the absolute path of the delivered file after compilation;

[0080] check_function:

[0081] RIP_Input_Patch,RIP6_Input_Patch,fwdutility_JiffiesTimerCallBack_Patch------Verification items;

[0082] app_name:forward------the name of the process involved;

[0083] depend_file: / sbin / forwardDependency process name (absolute path is required).

[0084] Further, a hash value of the configuration file is calculated, and the hash value is written into the configuration file. In one embodiment, the hash value of the configuration file is calculated, including:

[0085] After obtaining the patch delivery directory through the inspection function, the func_exec_update_md5 and func_init_patchcfg functions are used to process these patch sub-directory folders.

[0086] For each subdirectory to be calculated, a first configuration file is constructed, and the remaining contents of the original configuration file that do not contain hash value entries are copied to the first configuration file.

[0087] Specifically, call the func_init_patchcfg function to initialize the original patch.cfg configuration file and delete the old hash value entry "file_checksum:". First, concatenate the absolute path of the original configuration file patch.cfg under the patch delivery document with the patch subdirectory + patch.cfg, and assign the absolute path to NEW_CFG. NEW_CFG is a temporary file. If it exists, delete it. Create a NEW_CFG file, grant it read, write, and execute permissions, convert the format of the CFG_NAME file from DOS to Unix format, and discard the standard output. Read the contents of the patch.cfg file, and append all the contents except the line starting with file_checksum to the NEW_CFG file. Delete the original CFG_NAME file. Rename the NEW_CFG file to CFG_NAME to make it a new configuration file, that is, the first configuration file CFG_NAME.

[0088] With these steps, the patch.cfg file is initialized and the old file_checksum entry is removed, ready for updating the hash of the patch file.

[0089] Furthermore, the hash value under the hash value entry in the original configuration file is initialized; a second configuration file is constructed, and all contents in the original configuration file are copied to the second configuration file.

[0090] The hash value of the embodiment of the present application can be determined by the calculated MD5 value. Call the func_exec_update_md5 function to start updating the MD5 value in patch.cfg. Concatenate the patch subdirectory path with the patch.cfg file name to form the absolute path of the patch.cfg file. Assign the constructed absolute path to the variable newfilename. Create a new temporary file named new.cfg under the path specified by newfilename. If the new.cfg temporary file already exists, delete it to ensure that there is no interference from the old file before writing new data. Set appropriate permissions for the newly created new.cfg file to ensure that the file is readable and writable. Start a loop to read the contents of the original patch.cfg file line by line. Append each line of content read to the new.cfg temporary file line by line.

[0091] According to this step, the content of the original patch.cfg file can be completely copied to the second configuration file new.cfg.

[0092] Furthermore, the patch type and file name are extracted from the second configuration file, and a patch delivery path is constructed for a patch delivery of the target type.

[0093] Check whether the file content in the second configuration file new.cfg starts with patch_type. If so, extract the patch type through sed and assign it to the PATCH_TYPE variable. Then perform a nested conditional judgment. If the extracted PATCH_TYPE is empty, output an error message (used to determine whether it is a kernel-state patch. Kernel-state patches do not participate in the increment).

[0094] Furthermore, determine whether the file in new.cfg starts with filename. If so, use the sed command to extract the data after file_name and assign it to the PATCH_FILE variable; check whether the PATCH_FILE variable is empty to confirm whether the file name of the patch delivery is successfully extracted, and construct the REAL_PATCH_FILE variable by concatenating the patch subdirectory + filename to form the complete path of the patch delivery.

[0095] Furthermore, the patch delivery content is queried based on the patch delivery path, and the hash value of the patch delivery is calculated, and the hash value entry string content is added to the first configuration file, which is the updated configuration file, to obtain a configuration file containing the hash value.

[0096] Use the MD5 tool to calculate the MD5 checksum of the patch delivery indicated by the REAL_PATCH_FILE variable. The MD5sum tool will output a string containing the MD5 checksum and the file name. The complete output is stored in the variable FULL_MD5. Then pass the content of FULL_MD5 to awk and use awk to extract the first column (i.e., the MD5 value) and store it in the variable FILE_MD5.

[0097] Use the echo command to append the string "file_checksum" and the contents of the variable FILE_MD5 to the newFileName file. This step is done to update the configuration file and record the latest MD5 checksum of the file. Delete the original filename, which may contain old or outdated information. Rename the newFileName file to filename. Add the MD5 value of the patch delivery filename and the string "file_checksum" to the first configuration file CFG_NAME. The first configuration file is the configuration file patch.cfg of the updated patch delivery.

[0098] The configuration file patch.cfg after adding the file_checksum hash value includes:

[0099] patch_type:user_hot;-----Define the patch type;

[0100] board_type:mpu_x86;-----Defines the board type where the patch is installed;

[0101] file_name:libfwdplug_inetpatch_hs01.so;------patch delivery;

[0102] file_checksum:a3309a30b6db9290386b27480dea127c;hash value;

[0103] source_file:

[0104] TARGET / user_release / mpu_x86_64 / lib / libfwdplug_inetpatch_hs01.so; ---- the absolute path of the deliverable after compilation;

[0105] check_function:

[0106] RIP_Input_Patch,RIP6_Input_Patch,fwdutility_JiffiesTimerCallBack_Patch;------Verification entry;

[0107] app_name:forward;------Involved process name;

[0108] depend_file: / sbin / forwardDependency process name (absolute path is required).

[0109] The string "file_checksum:a3309a30b6db9290386b27480dea127c;" is the calculated hash value of the patch delivery, which is stored in the configuration file. According to this application, the MD5 value of the patch delivery can be calculated when packaging. After the record is completed, the patch is unpacked during the installation of the patch on the device. During the unpacking process, the patch.cfg file is first obtained, and the MD5 values ​​of the patch.cfg files in the new and old document directories are compared to see if they are consistent. If they are consistent, they are added to the whitelist, and patches in the whitelist are not added or deleted.

[0110] For ease of understanding, please refer to the attached Fig.12 Further description.

[0111] The configuration file hash value calculation method includes: first traversing all subdirectories under the directory to determine whether it is a special patch tool directory. If so, return to the first step. If not, copy the remaining contents of the non-hash value fields in the configuration file under the directory to the newly created first NEW.CFG file. Through these steps, the patch.cfg file is initialized, the old file_checksum entry is removed, and preparation is made for updating the checksum of the patch file.

[0112] Furthermore, a temporary second NEW.CFG file is created to determine whether the file already exists. If so, it is deleted to ensure that there is no interference from the old file before writing the new data. If not, the hash value field in the configuration file is initialized, and all the contents in the configuration file are copied to the second NEW.CFG file. The hash value of the filename delivery is obtained by concatenating the patch subdirectory with filename. The hash value field is added to the first NEW.CFG file, and the first configuration file is the latest configuration file after the hash value of the patch delivery is updated.

[0113] When unpacking, the patch delivery is added to the whitelist based on whether the hash values ​​in the configuration files of the new and old patch directories are consistent.

[0114] Based on the method of the present application, a hash value can be added to the configuration file of the patch delivery, and whether the patch delivery has changed can be determined based on the hash value. Patch delivery items that have not changed can be added to the whitelist.

[0115] S104 performs an upgrade based on the target patch deliverable.

[0116] In one embodiment, upgrading based on a target patch deliverable includes: when the target patch deliverable is a cold patch, executing a first upgrade strategy; the first upgrade strategy includes a strategy for upgrading based on replacement restart; when the target patch deliverable is a hot patch, executing a second upgrade strategy; the second upgrade strategy includes a strategy for upgrading based on function jump.

[0117] In one implementation, when the target patch deliverable is a cold patch, a first upgrade strategy is executed, including two situations: modifying the historical deliverable and only adding new content based on the historical deliverable.

[0118] In the case where the target patch delivery is a patch delivery that modifies the old version, the patch delivery under the old version is replaced based on the target patch delivery, and the process is restarted.

[0119] It can be combined with the upgrade method description in the prior art, such as Figure 2 The figure shows the process of upgrading the user-mode cold patch from the base version to HS01. In the figure, App1(HS01) is the HS01 patch delivery for this process, and App1(base) is the base version delivery for this process. HS01 installation process:

[0120] (1) App replacement: In the file system, App1(base) is replaced with App1(hs01), but App1(base) is still the one actually running.

[0121] (2) Process restart: Restart the process once, and the actual running process becomes App1 (hs01), and the patch takes effect.

[0122] Figure 3 This is the process of upgrading the user-mode cold patch from HS01 to HS02 in the prior art, which modifies the historical delivery Hs01. App1(HS01) is the HS01 patch delivery of the process, and App1(HS02) is the HS02 patch delivery of the process. The HS02 patch contains all the modifications of the HS01 patch, and the HS02 patch modifies the HS01 delivery.

[0123] The process of upgrading from HS01 to HS02:

[0124] Uninstall HS01;

[0125] (1) App replacement: In the file system, App1(HS01) is replaced with App1(base). The actual running app is still App1(HS01).

[0126] (2) Process restart: When the process is restarted for the first time, the actual running process becomes App1 (base) and the HS01 patch is uninstalled.

[0127] Install HS02;

[0128] (3) App replacement: In the file system, App1(base) is replaced with App1(HS02), but the actual running app is still App1(base).

[0129] (4) Process restart: When the process is restarted for the second time, the actual running process becomes App1 (HS02), and the HS02 patch is successfully installed and takes effect.

[0130] During this process, two process restarts were performed.

[0131] Figure 8 This is the process of upgrading the user-mode cold patch from HS01 to HS02, which modifies the historical delivery HS01.

[0132] App1(HS01) is the HS01 patch deliverable for the process, and App1(HS02) is the HS02 patch deliverable for the process. The HS02 patch contains all modifications to the HS01 patch, and the HS02 patch modifies the deliverable of HS01.

[0133] The process of upgrading from HS01 to HS02:

[0134] (1) App replacement: In the file system, App1 (HS01) is replaced with App1 (HS02). The actual running app is still App1 (HS01).

[0135] (2) Process restart: When the process is restarted for the first time, the actual running process becomes App1 (HS02), and the HS02 patch is successfully installed and takes effect.

[0136] It can be understood that based on the method of the present application, only one process restart is performed. The patch delivery under the old version is replaced based on the target patch delivery, and the process is restarted. There is no need to uninstall the patch delivery under the HS01 version.

[0137] In one implementation, when the target patch deliverable is a patch deliverable with new content added based on an old version, the patch deliverable under the base version is replaced based on the target patch deliverable, and the process is restarted.

[0138] like Figure 4 As shown, it is a process of upgrading a user-mode cold patch from HS01 to HS02 in the prior art, in which the historical deliverables are not modified.

[0139] App1(HS01) is the HS01 patch delivery, App1(HS01) & App2(HS02) are the HS02 patch delivery, and the HS02 patch delivery does not modify the HS01 patch delivery. The HS02 patch contains all the modifications of the HS01 patch.

[0140] The process of upgrading from HS01 to HS02:

[0141] Uninstall HS01:

[0142] (1) App replacement: In the file system, App1(HS01) is replaced with App1(base). The actual running app is still App1(HS01).

[0143] (2) Process restart: When the process App1 is restarted for the first time, the actual running process becomes App1(base) and the HS01 patch is uninstalled.

[0144] Install HS01 & HS02:

[0145] (1) App replacement: In the file system, App1(base) is replaced with App1(HS02), but App1(base) is still the one actually running.

[0146] When App2(base) is used to replace App2(HS02), App2(base) is still the one that is actually running.

[0147] (2) Process restart: When the process App1 is restarted for the second time, the actual running process becomes App1 (HS01), and the HS01 patch is successfully installed. When the process App2 is restarted for the first time, the actual running process becomes App2 (HS02), and the HS02 patch is successfully installed and takes effect.

[0148] During this process, three process restarts were performed. At this time, the HS01 patch delivery did not change. However, useless uninstalls and installs were performed.

[0149] Fig. 9 This is a user-mode cold patch for upgrading from HS01 to HS02. HS02 adds different processes.

[0150] App1 (HS01) is the HS01 patch delivery for this process, and App2 (HS02) is the HS02 patch delivery for this process. The HS02 patch contains all modifications to the HS01 patch. The HS02 patch does not modify the HS01 delivery. App1 and App2 are different processes.

[0151] The process of upgrading from HS01 to HS02:

[0152] (1) App replacement: In the file system, App2(base) is replaced with App2(HS02), but App2(base) is still the one actually running.

[0153] (2) Process restart: When the process App2 is restarted for the first time, the actual running process becomes App2 (HS02), and the HS02 patch is successfully installed and takes effect.

[0154] In the solution of this application, the App1 (HS01) deliverable is completely unchanged, and only the App2 (HS02) deliverable is installed. Only one process restart is performed during the process. Compared with the existing technical solution, two process restarts are reduced.

[0155] In the solution of the present application, when the target patch deliverable is a patch deliverable with new content added based on the old version, it is only necessary to replace the patch deliverable under the base version based on the target patch deliverable and restart the process.

[0156] In one embodiment, when the target patch delivery is a hot patch, executing the second upgrade strategy includes: when the target patch delivery is a patch delivery that modifies an old version, loading the target patch delivery in the file system and running it; when detecting that the program runs to a first target function that needs to be modified, jumping from the first target function in the old version of the patch delivery to the second target function in the target patch delivery. The first target function is a function in the HS01 version, and the second target function is a function in the HS02 version.

[0157] like Figure 5 The figure shows an existing user-mode hot patch upgrade process from a basic version to HS01.

[0158] HS01 installation process:

[0159] (1) Lib loading: In the file system, the HS01 patch delivery libpatch.so (HS01) is successfully loaded and run. So, the function is still running in the base version patch delivery libpatch.so (base).

[0160] (2) Function jump: When the patch tool runs to a specified modified function, it uses a jump instruction to cause the function to jump from the base version patch delivery libpatch.so (base) to the HS01 patch delivery libpatch.so (HS01).

[0161] Figure 6 It is the process of upgrading the existing user-mode hot patch from HS01 to HS02, and the historical deliverables have been modified.

[0162] HS01 uninstallation process:

[0163] (1) Canceling function jumps: When the patch uninstallation process runs to a specified modified function, the function will no longer execute jump instructions and will continue to run the function on the previous version, that is, the function in the base version patch delivery libpatch1.so (base).

[0164] HS02 installation process:

[0165] (1) Lib loading: In the file system, the HS02 patch delivery libpatch1.so (HS02) is successfully loaded and run. So, the function is still running in the base version patch delivery libpatch1.so (base).

[0166] (2) Function jump: When the patch tool runs to a specified modified function, it uses a jump instruction to cause the function to jump from the base version patch delivery libpatch1.so (base) to the HS02 patch delivery libpatch1.so (HS02).

[0167] Fig.10 This is the process of upgrading the user-mode hot patch from HS01 to HS02, which modifies the historical deliverables.

[0168] HS02 installation process:

[0169] (1) Lib loading: In the file system, the HS02 patch delivery libpatch1.so (HS02) is successfully loaded and run. So, the function is still running in the HS01 patch delivery libpatch1.so (HS01).

[0170] (2) Function jump: When the patch tool runs to the specified modified function, it uses the jump instruction to make the function jump directly from libpatch1.so(HS01) to libpatch1.so(HS02).

[0171] It can be seen that the solution of this application eliminates the HS01 function uninstallation process, and the HS0 version deliverables are completely unchanged, and only the HS02 version deliverables are installed.

[0172] In the case where the target patch delivery is a patch delivery of an old version with new content, the target patch delivery is loaded and run in the file system; when it is detected that the program runs to the third target function that needs to be modified, the third target function in the patch delivery of the base version is jumped to the second target function in the target patch delivery.

[0173] Figure 7 It is the process of upgrading the user-mode hot patch from HS01 to HS02 in the prior art, with new content added.

[0174] HS01 uninstallation process:

[0175] (1) Canceling function jumps: When the patch uninstallation process runs to a specified modified function, the function will no longer execute jump instructions and will continue to run the function in the previous version, that is, the function in libpatch1.so (base).

[0176] HS01$HS02 installation process:

[0177] (1) Lib loading: In the file system, HS02 patch delivery 2.so libpatch2.so (HS02) is successfully loaded and run.so. At this time, the function is still running in the basic version delivery & basic version delivery 2.so.

[0178] (2) Function jump: When running to a specified modified function, the patch tool uses a jump instruction to cause the function to jump from the basic version delivery & basic version delivery 2.so to the HS01 patch delivery & HS02 patch delivery 2.so.

[0179] Fig.11 This is the process of upgrading the user-mode hot patch from HS01 to HS02. The situation of adding new content.

[0180] HS02 installation process:

[0181] (1) Lib loading: In the file system, the HS02 patch delivery 2.so is successfully loaded and run.so. At this time, the function is still running in the basic version delivery 2.so.

[0182] (2) Function jump: When the patch tool runs to the specified modified function, it uses the jump instruction to make the function jump from libpatch2.so (base) to libpatch2.so (HS02).

[0183] During this process, the libpatch1.so (HS01) deliverable was not modified at all, and only the libpatch2.so (HS02) deliverable was installed.

[0184] Compared with the prior art, there is no HS01 unloading process, and only the HS02 function is loaded.

[0185] The solution of this application does not need to uninstall the historical deliverables when upgrading the delivered items that have changed. For cold patches, only replacement and restart are required. Compared with the existing technology, the number of restarts is greatly reduced. For the historical deliverables that have not been modified, they are still in the system and do not need to be uninstalled. For hot patches, the historical deliverables are also unchanged. The idle period when the historical patch deliverables are not in place is reduced.

[0186] Currently, the preconditions and precautions before installing a special patch can only be explained in the patch manual, which is complicated and not conducive to management and operation. If human inspection errors are made, installing the patch when the conditions are not met will trigger serious online problems. In addition, the post-installation finishing work can only be explained in the patch manual, which is not conducive to management and operation. If human inspection errors are made, problems caused by patch installation cannot be discovered in time.

[0187] In one embodiment, the method further includes: before performing a patch upgrade, calling a preset script to check whether the current environment has the conditions for installing the patch, and if the conditions are not met, returning a failure prompt.

[0188] In one embodiment, it also includes: before performing patch upgrade, calling a preset script to automatically perform pre-installation pre-processing; after executing the installation actions of all patches, calling a preset script to automatically perform post-patch installation processing.

[0189] For example, it provides patch installation preprocessing functions and post-installation finishing functions: when installing incremental patches, you can call scripts to perform pre-installation processing, such as recording logs, modifying files in memory, modifying the original patch delivery, etc.; after executing all patch installation actions, you can call scripts to perform post-installation finishing processing, such as recording logs, checking process status, etc., so that problems caused by patch installation will not be discovered in time due to human inspection errors.

[0190] According to another aspect of the embodiment of the present application, a software patch upgrade device for implementing the above-mentioned software patch upgrade method is also provided. Fig.13 As shown, the device comprises:

[0191] The acquisition module 201 is used to receive an upgrade instruction and acquire a patch file package of a new version;

[0192] The checking module 202 is used to call the checking function in the patch file package, traverse all subdirectories in the patch file package, and obtain the patch delivery directory;

[0193] The parsing module 203 is used to obtain the changed target patch deliverable from the patch file package when the deliverable in the patch deliverable directory changes;

[0194] The upgrade module 203 is used to perform an upgrade based on the target patch deliverable.

[0195] It should be noted that the software patch upgrade device provided in the above embodiment only uses the division of the above functional modules as an example when executing the software patch upgrade method. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the software patch upgrade device provided in the above embodiment and the software patch upgrade method embodiment belong to the same concept, and the implementation process thereof is detailed in the method embodiment, which will not be repeated here.

[0196] According to another aspect of the embodiments of the present application, an electronic device corresponding to the software patch upgrade method provided in the above embodiments is also provided to execute the above software patch upgrade method.

[0197] Please refer to Fig.14 , which shows a schematic diagram of an electronic device provided by some embodiments of the present application. Fig.14 As shown, the electronic device includes: a processor 300, a memory 301, a bus 302 and a communication interface 303, and the processor 300, the communication interface 303 and the memory 301 are connected via the bus 302; the memory 301 stores a computer program that can be run on the processor 300, and when the processor 300 runs the computer program, it executes the software patch upgrade method provided in any of the aforementioned embodiments of the present application.

[0198] The memory 301 may include a high-speed random access memory (RAM), and may also include a non-volatile memory, such as at least one disk memory. The communication connection between the system network element and at least one other network element is realized through at least one communication interface 303 (which may be wired or wireless), and the Internet, wide area network, local area network, metropolitan area network, etc. may be used.

[0199] The bus 302 may be an ISA bus, a PCI bus, or an EISA bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. The memory 301 is used to store programs, and the processor 300 executes the programs after receiving the execution instruction. The software patch upgrade method disclosed in any implementation of the above-mentioned embodiment of the present application may be applied to the processor 300, or implemented by the processor 300.

[0200] The processor 300 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit or software instructions in the processor 300. The above processor 300 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a readily available programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in the embodiments of the present application can be directly embodied as a hardware decoding processor to be executed, or the hardware and software modules in the decoding processor can be executed. The software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 301, and the processor 300 reads the information in the memory 301 and completes the steps of the above method in combination with its hardware.

[0201] The electronic device provided in the embodiment of the present application and the software patch upgrade method provided in the embodiment of the present application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented therein.

[0202] According to another aspect of the embodiments of the present application, a computer-readable storage medium corresponding to the software patch upgrade method provided in the aforementioned embodiments is also provided, on which a computer program (i.e., a program product) is stored. When the computer program is run by a processor, it will execute the software patch upgrade method provided in any of the aforementioned embodiments.

[0203] It should be noted that examples of computer-readable storage media may also include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical or magnetic storage media, which are not listed here one by one.

[0204] The computer-readable storage medium provided in the above-mentioned embodiment of the present application and the software patch upgrade method provided in the embodiment of the present application are based on the same inventive concept and have the same beneficial effects as the method adopted, run or implemented by the application program stored therein.

[0205] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0206] The above embodiments only express several implementation methods of the present invention, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present invention. It should be pointed out that, for a person of ordinary skill in the art, several modifications and improvements can be made without departing from the concept of the present invention, and these all belong to the protection scope of the present invention. Therefore, the protection scope of the present invention patent shall be subject to the attached claims.

Claims

1. A software patch upgrade method, characterized in that: include: Receive upgrade instructions and obtain the patch file package of the new version; Calling the check function in the patch file package, traversing all subdirectories in the patch file package, and obtaining a patch delivery directory; When a deliverable in the patch deliverable directory changes, obtaining the changed target patch deliverable from the patch file package; An upgrade is performed based on the target patch deliverable.

2. The method according to claim 1, characterized in that Upgrade based on the target patch deliverables, including: In the case where the target patch delivery is a cold patch, executing a first upgrade strategy; the first upgrade strategy includes a strategy for upgrading based on replacement and restart; In the case where the target patch delivery is a hot patch, executing a second upgrade strategy; the second upgrade strategy includes an upgrade strategy based on function jump; Among them, a cold patch is a patch that requires a device restart to run after installation, and a hot patch is a patch that can be run without a device restart after installation.

3. The method according to claim 2, characterized in that When the target patch delivery is a cold patch, executing a first upgrade strategy includes: In the case where the target patch deliverable is a patch deliverable in an old version that is modified, replacing the patch deliverable in the old version based on the target patch deliverable, and restarting the process; In the case that the target patch delivery is a patch delivery of the old version with new content, the patch delivery of the base version is replaced based on the target patch delivery, and the process is restarted.

4. The method according to claim 2, characterized in that: When the target patch delivery is a hot patch, executing a second upgrade strategy includes: In the case where the target patch delivery is a patch delivery in an old version that is modified, loading and running the target patch delivery in the file system; when detecting that the program runs to a first target function that needs to be modified, jumping from the first target function in the patch delivery in the old version to a second target function in the target patch delivery; In the case that the target patch delivery is a patch delivery of the old version with newly added content, the target patch delivery is loaded and run in the file system; when it is detected that the program runs to the third target function that needs to be modified, the third target function in the patch delivery of the base version is jumped to the second target function in the target patch delivery.

5. The method according to claim 1, characterized in that In the case where the deliverable in the patch deliverable directory changes, before obtaining the changed target patch deliverable from the patch file package, the method further includes: Parsing the patch file package to obtain a hash value of a configuration file of the patch delivery under the new version; Get the hash value of the configuration file of the patch delivery under the old version in the system; Generate a whitelist based on the hash values ​​of the configuration files in the new and old versions, where the whitelist contains patch deliverables that have not changed; The patch deliverables that do not belong to the whitelist are obtained from the patch file package to obtain the changed target patch deliverables.

6. The method according to claim 5, characterized in that Before parsing the patch file package, the following steps are also included: A configuration patch file package, wherein a subdirectory of the patch file package includes a configuration file; Calculating a hash value of the configuration file; A hash value of the configuration file is added to the configuration file.

7. The method according to claim 6, characterized in that Calculating a hash value of the configuration file and adding the hash value of the configuration file to the configuration file includes: Traverse all subdirectories under the patch file package directory and identify the subdirectories to be calculated; For each subdirectory to be calculated, construct a first configuration file, and copy the remaining contents of the original configuration file that do not contain the hash value entries to the first configuration file; Initialize the hash value under the hash value entry in the original configuration file; construct a second configuration file, and copy all the contents in the original configuration file to the second configuration file; Extracting the patch type and file name from the second configuration file, and constructing a patch delivery path for a patch delivery of a target type; The patch delivery item content is queried based on the patch delivery item path, and a hash value of the patch delivery item is calculated. The hash value item string content is added to the first configuration file to obtain a configuration file containing the hash value.

8. A software patch upgrade device, characterized in that: include: The acquisition module is used to receive the upgrade instruction and obtain the patch file package of the new version; A check module, used to call the check function in the patch file package, traverse all subdirectories in the patch file package, and obtain a patch delivery directory; A parsing module, configured to obtain a changed target patch deliverable from the patch file package when a deliverable in the patch deliverable directory changes; An upgrade module is used to perform an upgrade based on the target patch deliverable.

9. An electronic device, characterized in that: The invention comprises a processor and a memory storing program instructions, wherein the processor is configured to execute the software patch upgrade method according to any one of claims 1 to 7 when executing the program instructions.

10. A computer-readable medium, characterized in that Computer-readable instructions are stored thereon, and the computer-readable instructions are executed by a processor to implement a software patch upgrade method as described in any one of claims 1 to 7.

Images