System Migration Compatibility Analysis Method, Device, Computer Equipment and Storage Medium

Abstract

The present invention relates to the technical field of system migration, and discloses a system migration compatibility analysis method, device, computer device and storage medium, including: obtaining a binary file of software to be analyzed; querying the dependency relationship of the binary file to determine whether the dependent file on which the binary file depends is a boundary rpm package; when the dependent file on which the binary file depends is not a boundary rpm package, recursively querying the dependency relationship of the dependent file until the dependent file is a boundary rpm package; when the dependent file on which the binary file depends is a boundary rpm package, querying the ABI interface on which the dependent file depends, and determining the compatibility of the software to be analyzed in the target operating system based on the ABI interface on which the dependent file depends. The present invention changes the compatibility difference from all existing retained files to boundary rpm packages, reduces the performance consumption and implementation difficulty of migration analysis, and greatly improves the migration efficiency and practical feasibility.

Description

Technical Field

[0001] The present invention relates to the technical field of software operating systems, and particularly to a method, apparatus, computer device and storage medium for system migration compatibility analysis. Background Art

[0002] Enterprise users have a continuous maintenance requirement for the server operating systems they use. The maintenance cycle of the operating system is generally about 5 years. After the expiration, customers will face the need to update to a new operating system. However, at this time, their own business software and business data often have characteristics such as long development cycles, many iterations, changes in suppliers, and frequent changes in maintenance personnel, making it difficult to deploy the original business applications in the new operating system environment. For such an environment, customers will require the system migration implementer to change the operating system in the way of "in-place migration", that is, to keep the original hardware platform or virtual hardware platform and the upper-layer business applications unchanged, and only replace the components provided by the operating system to achieve the change of the operating system.

[0003] In the related art, major system manufacturers mostly adopt the "in-place migration" solution, and their implementation methods are similar. Without reinstalling the operating system, the underlying components of the system are replaced, and the kernel modules are reloaded to achieve the goal of minimizing the technical threshold for customers to complete the operating system change. However, in the process of implementing "in-place migration", a new problem will be introduced: the replacement of software before and after migration is not a smooth replacement. That is, there must be some software packages in the pre-migration system that do not have corresponding replacement components in the post-migration system, and some packages have a dependency relationship with the upper-layer software of the user in the original system, and the target operating system may also provide corresponding packages, but the support interfaces for the upper-layer software are not compatible. The existing compatibility analysis of the migration system requires traversing all software packages and their corresponding dependent software, which takes a long time and is inefficient, resulting in unsatisfactory efficiency and practical feasibility of the migration method. Summary of the Invention

[0004] In view of this, the present invention provides a method, apparatus, computer device and storage medium for system migration compatibility analysis to solve the problem of long time-consuming and low efficiency of the existing compatibility analysis.

[0005] In a first aspect, the present invention provides a method for system migration compatibility analysis, the method comprising:

[0006] Obtain the binary file of the software to be analyzed;

[0007] Query the dependency relationship of the binary file, and based on the dependency relationship, determine whether the dependent file on which the binary file depends is a boundary rpm package, and the boundary rpm package is used to represent the binary file replaced by the dependent file in the target operating system;

[0008] When the dependent file of the binary file depends on a non-boundary rpm package, recursively query the dependency relationship of the dependent file until the dependent file is a boundary rpm package;

[0009] When the dependent file of the binary file is a boundary rpm package, determine that the compatibility of the binary file is consistent with the compatibility of the dependent file;

[0010] Query the ABI interfaces on which the dependent file depends, and based on the ABI interfaces on which the dependent file depends, determine the compatibility of the software to be analyzed on the target operating system.

[0011] In the present invention, starting from the differences between the two operating systems in terms of changes and the software installed in the software repositories and systems after the changes, query the dependency relationships of the binary files in the software to be analyzed, pre-search for boundary rpm packages, determine that the compatibility of the binary files depends on the dependent files, judge whether the dependent files are boundary rpm packages, and when the dependent files of the binary files are non-boundary rpm packages, recursively until the dependent files of the binary files are boundary rpm packages and then perform compatibility analysis. The comparison operation domain of compatibility differences has changed from analyzing the compatibility of all retained files in the prior art to only analyzing the compatibility of boundary rpm packages, so that the compatibility of all retained files can be determined, greatly reducing the workload of analysis, reducing the performance consumption and implementation difficulty of migration analysis, and greatly improving the migration efficiency and practical feasibility.

[0012] In an alternative implementation, obtaining the binary files of the software to be analyzed includes:

[0013] Obtain the application software installation directory of the source operating system and the application software installation directory of the target operating system;

[0014] Based on the application software installation directory of the source operating system and the application software installation directory of the target operating system, screen to obtain the binary files of the software to be analyzed;

[0015] And / or, obtain the application software packages of the source operating system, and screen to obtain the binary files of the software to be analyzed;

[0016] Obtain the system software installed in the source operating system and the pre-constructed data base, and the pre-constructed data base is used to represent the difference data table between the source operating system and the target operating system;

[0017] Query the data base, screen to obtain the software packages to be retained on the target operating system, and query the binary files included in the retained software packages.

[0018] In this method, the binary file of the software to be analyzed is obtained by screening the application software installation directories of the source operating system and the target operating system, and the binary file of the software to be analyzed can also be obtained by screening the application software packages of the source operating system. The binary files of the software to be retained are obtained by screening through the data base, realizing the acquisition of the binary files corresponding to all the software that needs to be retained in the target operating system, which is convenient for subsequent compatibility analysis of the software in the target operating system using the binary files.

[0019] In an optional implementation manner, the data base is prepared through the following steps:

[0020] Determine the dynamic library file to be analyzed;

[0021] Obtain the rpm package to which the dynamic library file to be analyzed belongs in the source operating system and the rpm package to which it belongs in the target operating system;

[0022] Based on the rpm package to which the dynamic library file to be analyzed belongs in the source operating system and the rpm package to which it belongs in the target operating system, query the debug file corresponding to the dynamic library file to be analyzed in the source operating system and the debug file corresponding to the dynamic library file to be analyzed in the target operating system;

[0023] Based on the debug file corresponding to the dynamic library file to be analyzed in the source operating system and the debug file corresponding to the dynamic library file to be analyzed in the target operating system, generate the ABI difference data of the dynamic library file to be analyzed to obtain the data base.

[0024] In this method, by pre-preparing a data base for characterizing the differences between the source operating system and the target operating system, the workload of traversing all the software in the source operating system and the target operating system is reduced, the time consumed for compatibility analysis is greatly reduced, and the working efficiency of compatibility analysis is further improved.

[0025] In an optional implementation manner, query the dependency relationship of the binary file. Based on the dependency relationship, determine whether the dependent file on which the binary file depends is a boundary rpm package, including:

[0026] Query the so library file on which the binary file depends;

[0027] Based on the data base, query the rpm package to which the so library file belongs in the target operating system and determine whether the rpm package is retained;

[0028] When the rpm package is not retained, determine that the dependent file on which the binary file depends is a boundary rpm package;

[0029] When the rpm package is retained, determine that the dependent file on which the binary file depends is not a boundary rpm package.

[0030] In this method, when the RPM packages on which the binary file depends are not retained, the recursion is carried out until the dependent file on which the binary file depends is the boundary RPM package, and then the compatibility analysis is performed. The key difference points in the compatibility analysis of the two operating systems after the change are locked in the boundary RPM package, thus greatly reducing the workload of the analysis, reducing the computational amount in the migration evaluation link, and further improving the migration efficiency and practical feasibility.

[0031] In an optional implementation manner, based on the data base, query the RPM packages to which the SO library files belong in the target operating system, including:

[0032] Query the data base to obtain the RPM packages in the target operating system corresponding to the RPM packages in the source operating system;

[0033] Based on the names of the RPM packages in the target operating system, query the RPM-SO correspondence table in the data base to determine whether there is an SO library corresponding to the RPM packages in the target operating system in the target operating system;

[0034] When there is no SO library corresponding to the RPM packages in the target operating system in the target operating system, it is determined that the software to be analyzed is incompatible in the target operating system.

[0035] In this method, by using the pre-constructed data base, query the RPM packages in the target operating system corresponding to the RPM packages in the source operating system, query the RPM-SO correspondence table in the data base, determine whether there is an SO library corresponding to the RPM packages in the target operating system in the target operating system, and when there is no SO library corresponding to the RPM packages in the target operating system in the target operating system, it is determined that the software to be analyzed is incompatible in the target operating system, reducing the computational amount in the migration evaluation link and further improving the migration efficiency and practical feasibility.

[0036] In an optional implementation manner, query the ABI interfaces on which the dependent files depend, and based on the ABI interfaces on which the dependent files depend, determine the compatibility of the software to be analyzed in the target operating system, including:

[0037] When there is an SO library corresponding to the RPM packages in the target operating system in the target operating system, read the ABI interfaces on which the SO library depends;

[0038] Query the ABI interface difference table between the source operating system and the target operating system in the data base to determine whether the ABI interfaces on which the SO library depends hit the ABI interface difference table;

[0039] When the ABI interfaces on which the SO library depends hit the ABI interface difference table, it is determined that the software to be analyzed is incompatible in the target operating system;

[0040] When the ABI interface relied on by the so library does not match the ABI interface difference table, it is determined that the software to be analyzed is compatible with the target operating system.

[0041] In this method, when there is an so library corresponding to the rpm package in the target operating system, by using the pre-constructed data base, querying the ABI interface difference table between the source operating system and the target operating system in the data base, it is possible to determine the binary file in a direct table lookup manner, reducing the computational effort in the migration evaluation link and further improving the migration efficiency and practical feasibility.

[0042] In a second aspect, the present invention provides a system migration compatibility analysis device, which includes:

[0043] A file acquisition module for acquiring the binary file of the software to be analyzed;

[0044] A dependency relationship query module for querying the dependency relationship of the binary file, and based on the dependency relationship, determining whether the dependency file relied on by the binary file is a boundary rpm package, where the boundary rpm package is used to represent the binary file replaced by the dependency file in the target operating system;

[0045] A recursive query module for recursively querying the dependency relationship of the dependency file when the dependency file relied on by the binary file is not a boundary rpm package until the dependency file is a boundary rpm package;

[0046] A compatibility determination module for determining that the compatibility of the binary file is consistent with the compatibility of the dependency file when the dependency file relied on by the binary file is a boundary rpm package;

[0047] An ABI analysis module for querying the ABI interface relied on by the dependency file, and based on the ABI interface relied on by the dependency file, determining the compatibility of the software to be analyzed in the target operating system.

[0048] In a third aspect, the present invention provides a computer device, including: a memory and a processor, which are communicatively connected to each other, and the memory stores computer instructions, and the processor executes the computer instructions to execute the system migration compatibility analysis method according to the first aspect or any corresponding embodiment thereof.

[0049] In a fourth aspect, the present invention provides a computer-readable storage medium, on which computer instructions are stored, and the computer instructions are used to cause a computer to execute the system migration compatibility analysis method according to the first aspect or any corresponding embodiment thereof.

[0050] Fifthly, the present invention provides a computer program product, including computer instructions for causing a computer to execute the system migration compatibility analysis method according to the first aspect or any corresponding embodiment thereof as described above. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for use in the description of the specific embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0052] Figure 1 is a schematic flowchart of the system migration compatibility analysis method according to an embodiment of the present invention.

[0053] Figure 2 is a schematic diagram of the principle of ABI-based analysis according to an embodiment of the present invention.

[0054] Figure 3 is a schematic diagram of an example of a boundary rpm when the source and target operating systems change according to an embodiment of the present invention.

[0055] Figure 4 is a schematic diagram of the recursive logic for analyzing the compatibility of retained software according to an embodiment of the present invention.

[0056] Figure 5 is a schematic flowchart of another system migration compatibility analysis method according to an embodiment of the present invention.

[0057] Figure 6 is a schematic diagram of finding an elf file to be analyzed according to an embodiment of the present invention.

[0058] Figure 7 is a schematic flowchart of yet another system migration compatibility analysis method according to an embodiment of the present invention.

[0059] Figure 8 is a schematic diagram of analyzing the dependency relationship of an elf file according to an embodiment of the present invention.

[0060] Figure 9 is a schematic diagram of presenting the analysis results according to an embodiment of the present invention.

[0061] Figure 10 is a block diagram of the structure of the system migration compatibility analysis device according to an embodiment of the present invention.

[0062] Figure 11 is a schematic diagram of the hardware structure of the computer device according to an embodiment of the present invention. Detailed Implementation Manner

[0063] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Apparently, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0064] In related technologies, major system manufacturers mostly adopt the "in-place migration" solution, and their implementation methods are similar. Without reinstalling the operating system, the underlying system components are replaced, and the kernel modules are reloaded to achieve the goal of minimizing the technical threshold for customers to complete the operating system change. However, during the implementation of "in-place migration", a new problem will be introduced: the replacement of software before and after migration is not a smooth replacement. That is, there must be some software packages in the system before migration that do not have corresponding replacement components in the system after migration, and some packages have a dependency relationship with the upper-layer software of the user in the original system. Although the target operating system may also provide corresponding packages, the support interfaces for the upper-layer software are not compatible. The existing compatibility analysis of the migrated system needs to traverse all software packages and their corresponding dependent software, which takes a long time and is inefficient, resulting in unsatisfactory efficiency and practical feasibility of the migration method.

[0065] To solve the problem of whether application software can be compatibly run in the new system, the prior art also uses the method of virtual environment simulation. For example, in CN117555876A, it is a simulation running method based on a virtual file system. However, this method requires the customer to have a precise understanding of the deployment, operation, and operation and maintenance of their own business software. In reality, it is really difficult for the customer side to concentrate on how to operate their own business and be well-versed in the "business tools" they use. This is also a pain point in the current migration work industry.

[0066] There is also a method of evaluating based on the compatibility of the operating system basic suite. For example, CN115469928A. However, it is still a minority for application software to directly use the basic suite to run its own business logic, or only scripted programs will do so. Compiled programs often directly call the symbols of the system basic library to interact with the operating system and efficiently complete their own functions. Such software is often industrial-level business software used by enterprises, and its compatibility still has to start from the basic library symbols provided by the operating system it depends on.

[0067] To solve the above problems, an embodiment of the present invention provides a system migration compatibility analysis method for use in a computer device. It should be noted that the execution subject can be a system migration compatibility analysis device, which can be implemented as part or all of the computer device through software, hardware, or a combination of both. Among them, the computer device can be a terminal, a client, or a server. The server can be a single server or a server cluster composed of multiple servers. The terminal in the embodiments of the present application can be other intelligent hardware devices such as a smart phone, a personal computer, or a tablet computer. In the following method embodiments, the execution subject is taken as a computer device as an example for description.

[0068] The computer device in this embodiment is applicable to the usage scenario of analyzing the compatibility of the upper-layer application software version and service configuration in the new system environment when replacing only the components provided by the operating system while keeping the original hardware platform or virtual hardware platform and the upper-layer service applications unchanged under the condition of updating to a new operating system. Through the system migration compatibility analysis method provided by the present invention, starting from the differences between the two operating systems before and after the change and the software already installed in the software repository and system after the change, query the dependency relationship of the binary files in the software to be analyzed, pre-search for the boundary rpm packages, determine that the compatibility of the binary files depends on the dependent files, judge whether the dependent files are boundary rpm packages, and when the dependent files on which the binary files depend are not boundary rpm packages, recursively push until the dependent files on which the binary files depend are boundary rpm packages and then perform compatibility analysis. The comparison operation domain of compatibility differences is changed from analyzing the compatibility of all retained files in the prior art to only analyzing the compatibility of boundary rpm packages, so that the compatibility of all retained files can be determined, greatly reducing the workload of analysis, reducing the performance consumption and implementation difficulty of migration analysis, and greatly improving the migration efficiency and practical feasibility.

[0069] According to an embodiment of the present invention, an embodiment of a system migration compatibility analysis method is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions. And although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0070] In this embodiment, a system migration compatibility analysis method is provided, which can be used for the above-mentioned computer device. Figure 1 is a flowchart of the system migration compatibility analysis method according to an embodiment of the present invention, as Figure 1 shown. The process includes the following steps:

[0071] Step S101, obtain the binary files of the software to be analyzed.

[0072] In one example, the binary file includes a binary file program that can be directly executed and library files stored in the system. Since these files are all compiled binary files, the file content cannot be viewed in plain text. Also, because their types in the operating system are all "ELF 64-bit LSB shared object", they are simply referred to as elf files.

[0073] Step S102: Query the dependency relationship of the binary file. Based on the dependency relationship, determine whether the dependent file on which the binary file depends is a boundary rpm package.

[0074] In the embodiment of the present invention, the boundary rpm package is used to represent the binary file that replaces the dependent file in the target operating system.

[0075] In one example, if the rpm package on which the upper-layer binary file depends is replaced in the target operating system, then this binary file is a boundary rpm package.

[0076] Step S103: When the dependent file on which the binary file depends is not a boundary rpm package, recursively query the dependency relationship of the dependent file until the dependent file is a boundary rpm package.

[0077] In one example, if the rpm package on which the upper-layer binary file depends has a lower layer and the rpm package of its lower layer is replaced, that is, "the dependent package of a certain rpm package is a boundary rpm package", then its compatibility is determined by the compatibility of the boundary rpm package on which it depends.

[0078] Step S104: When the dependent file on which the binary file depends is a boundary rpm package, determine that the compatibility of the binary file is consistent with the compatibility of the dependent file.

[0079] In one example, if the rpm package on which the upper-layer binary file depends is replaced, then this binary file is a boundary rpm package, and the compatibility of this binary file needs to be analyzed. The compatibility of this binary file depends on whether there is a corresponding so library support in the target operating system for the so library file on which it depends.

[0080] Step S105: Query the ABI interface on which the dependent file depends. Based on the ABI interface on which the dependent file depends, determine the compatibility of the software to be analyzed in the target operating system.

[0081] In one example, the ABI (Application Binary Interface) defines the interaction specifications between an application and the operating system, libraries, and hardware at the binary level. Specifically, the ABI is a low-level interface convention that stipulates how an application interacts with the operating system, libraries, and other binary program modules. These interactions, including function calls, parameter passing, memory layout, system calls, etc., are defined in detail at the binary level. Figure 2 is a schematic diagram of the principle of ABI-based analysis according to an embodiment of the present invention, as Figure 2 shown, to determine whether a software package can run on a new system, ultimately it is to determine whether the external interfaces called by its binary file (compiled program) can be provided in the new system, and whether the provided interfaces are compatible with the interfaces provided by the source operating system.

[0082] Exemplarily, from the usage perspective, these interfaces appear in the form of function names and data structure calls, and are called symbols. These interfaces exist in the system dynamic library files, that is, files in the form of "libxxx.so". From the debugging perspective, the description information of the binary interface, including function declarations, data structure descriptions, and build-related information, is called the ABI interface. These information are stored in the debug package corresponding to the software package. That is, if the name of a released software package is "{name}-{version}-{arch}.rpm", then the manufacturer generally also releases the corresponding version of the debug package "{name}-debuginfo-{version}-{arch}.rpm", which contains the debug files corresponding to the dynamic library files provided by the software package, and its naming is generally "{dynamic library name}.debug", which stores the debug information about the function implementation. The differences in the ABI interfaces (including but not limited to function changes, data structure changes, etc.) between two dynamic libraries with the same name in different versions can be compared through open-source tools such as abi-dumper and abicc.

[0083] In one implementation scenario, for the process of in-place migration of the operating system, the essential process is divided into three parts: 1) Check the basic packages at the system layer installed in the source operating system and replace them with the corresponding software packages of the target operating system. 2) Replace the software repository source used by the source operating system with the software repository source of the target operating system. 3) Conduct compatibility dependency analysis on the upper-layer software that cannot be replaced in the source operating system, and take measures such as retention, deletion, or avoidance according to the analysis results.

[0084] In the system migration scenario, if the system meets the following ideal conditions: 1. There are not significant differences in the software repository architecture organization between the two operating systems; 2. The forms of software changes in the two operating systems are mostly version updates, without involving situations such as package merging, splitting, renaming, and abandonment. In this case, the conventional approach only requires configuring the software repository address of the system to the target operating system repository address, and then using the system's dnf software management tool to execute the upgrade operation (the command is dnf upgrade). At this time, the software management tool will automatically determine which upgradable packages of the software components already installed in the current system are available in the new repository and perform the upgrade operation.

[0085] However, in the actual situation of system migration, it is often a system change scenario between different vendors and across major versions. When using the same operation, the following situations will occur: 1. The organizational structures of the software repositories of the two systems are inconsistent. 2. When a major version is updated for the same package, there are significant changes, such as the rpm package being split, merged, renamed, abandoned, or having its repository location changed in the new version. In this case, the system's software management tool cannot find the available updated components of the software in the new repository. No matter how it is handled, there will inevitably be some software packages of the source operating system that cannot directly find replacement components in the target operating system and are retained. This includes the following three situations:

[0086] 1. Operating system full - change model: Compare all the software in all the standard repositories of the source operating system and the target operating system. This model determines the upper limit of the boundary for compatibility analysis. Taking the migration from the centos7 operating system to the Changqing 24 operating system as an example, its standard repositories are: the base repository, the update repository, and the extras repository. While the standard repository of the Changqing 24 system is uniformly the everything repository. Then analyze the differences between the two in full, and through comparison, determine what operations should be taken for the rpm packages in the source operating system in the target operating system and record them in the implementation configuration file of the migration tool to guide its behavior (the behaviors include: how to replace packages: replacement, merging, splitting, renaming, changing repositories, abandonment, etc., which are not restricted in the present invention). Prepare the data base according to the full - scale analysis domain. The number of software packages encountered in the actual user operating system environment is less than that of the data base, that is, the software that the user actually needs to analyze is a subset of the prepared data base. It provides the source and theoretical basis for the preparation of the data base, corresponding to the Figure 2 first part above.

[0087] 2. Migration model for retaining some original system packages: During the migration between two operating systems, some packages cannot be directly replaced. After the migration of the two operating systems, some packages that existed in the source operating system have been abandoned in the target operating system; the new versions are merged but there are no corresponding packages in the target operating system; the new versions are split but the target operating system uses some of the packages; a certain package in the source operating system is maintained in another repository in the target operating system and its name has changed, etc., resulting in some packages of the source operating system being retained in the target operating system after migration. The significance of this model is that it is one step closer to the actual migration scenario. Because of the old packages retained during the migration process, whether these old packages can run properly in the target operating system is an analysis domain that requires compatibility analysis, corresponding to the middle part of the above Figure 2 the middle part.

[0088] 3. Migration model considering customer business applications and actual dependencies: Figure 3 It is a schematic diagram of an example of the boundary rpm when the source and target operating systems are changed according to an embodiment of the present invention. As Figure 3 shown, the software in the actual customer environment has the following parts: software packages provided by the basic yum source of the source operating system, installed in the customer environment, and will be replaced by the corresponding package group of Changqing in the json file ( Figure 3 the part within the solid line frame in Figure 3 ); parts found in the source operating system but retained in the json file (

[0089] the part within the dashed line frame in

[0090] ), and these retained parts are further divided into the following situations:

[0091] 1) It is the yum source of the source operating system, but is retained in the json file due to reasons such as "merging, renaming, abandonment, dependencies, etc.".

[0092] 2) It is not the system yum source, but packages installed by the customer to meet the needs of the upper-layer business.

[0093] During the system migration process, the source operating system repository packages that have been discovered are replaced through json, and the replaced part of the target operating system rpm packages can be self-consistent (the part within the solid line frame in the figure).

[0094] After the system migration process, the RPM packages retained by the source operating system (the part within the dashed box in the figure) may not necessarily have consistent internal dependency relationships and compatibility. The reasons are as follows:

[0095] If the RPM package depended on by the upper-layer package has no further lower-layer dependencies, it can be self-consistent.

[0096] If the RPM package depended on by the upper-layer package is replaced, the compatibility of this package needs to be analyzed - it is classified as a boundary RPM package (the part of the bold dashed line in the figure). And the compatibility of this package depends on whether there is a corresponding SO library support in the target operating system for the SO library files it depends on (the part of the bold solid line in the figure).

[0097] If the upper-layer package depends on an RPM package that has a lower layer and the lower-layer RPM package is replaced, that is, "the dependent package of a certain RPM package is a boundary RPM package", then its compatibility is determined by the compatibility of the boundary RPM package it depends on. Figure 4 It is a schematic diagram of a recursive logic for analyzing the compatibility of retained software according to an embodiment of the present invention. As Figure 4 shown, let the compatibility of the boundary ELF be elf0, the compatibility of a certain ELF be elf n , and the compatibility of the binary file directly depended on by a certain ELF be elf n-1 . The recursive formula for the dependency relationship is as follows:

[0098]

[0099] The compatibility of numerous upper-layer ELF files in the target operating system can be directly attributed to "the compatibility of the boundary ELF".

[0100] The system migration compatibility analysis method provided in this embodiment starts from the differences between the two operating systems in terms of changes and the software repositories and installed software after the changes, queries the dependency relationships of binary files in the software to be analyzed, pre-searches for boundary RPM packages, determines that the compatibility of binary files depends on the dependent files, judges whether the dependent files are boundary RPM packages, and when the dependent files of the binary files are not boundary RPM packages, recursively proceeds until the dependent files of the binary files are boundary RPM packages and then conducts compatibility analysis. This changes the comparison operation domain of compatibility differences from analyzing the compatibility of all retained files in the prior art to only analyzing the compatibility of boundary RPM packages, thereby determining the compatibility of all retained files, greatly reducing the workload of analysis, reducing the performance consumption and implementation difficulty of migration analysis, and significantly improving the migration efficiency and practical feasibility.

[0101] In this embodiment, a system migration compatibility analysis method is provided, which can be used for the above-mentioned computer device. Figure 5is a flowchart of another system migration compatibility analysis method according to an embodiment of the present invention. As Figure 5 shown, the process includes the following steps:

[0102] Step S501, obtain the binary file of the software to be analyzed.

[0103] Specifically, the above step S501 includes:

[0104] Step S5011, obtain the application software installation directory of the source operating system and the application software installation directory of the target operating system.

[0105] Step S5012, based on the application software installation directory of the source operating system and the application software installation directory of the target operating system, screen and obtain the binary file of the software to be analyzed.

[0106] Step S5013, and / or, obtain the application software package of the source operating system, and screen and obtain the binary file of the software to be analyzed.

[0107] Step S5014, obtain the system software installed in the source operating system and the pre-constructed data base.

[0108] In the embodiment of the present invention, the pre-constructed data base is used to represent the difference data table between the source operating system and the target operating system.

[0109] In some alternative embodiments, the data base is prepared through the following steps:

[0110] Step a1, determine the dynamic library file to be analyzed.

[0111] Step a2, obtain the rpm package to which the dynamic library file to be analyzed belongs in the source operating system and the rpm package to which the dynamic library file to be analyzed belongs in the target operating system.

[0112] Step a3, based on the rpm package to which the dynamic library file to be analyzed belongs in the source operating system and the rpm package to which the dynamic library file to be analyzed belongs in the target operating system, query and obtain the debug file corresponding to the dynamic library file to be analyzed in the source operating system and the debug file corresponding to the dynamic library file to be analyzed in the target operating system.

[0113] Step a4, based on the debug file corresponding to the dynamic library file to be analyzed in the source operating system and the debug file corresponding to the dynamic library file to be analyzed in the target operating system, generate the ABI difference data of the dynamic library file to be analyzed to obtain the data base.

[0114] In one example, the general approach to analyzing whether the ABIs of a certain dynamic library provided by two operating systems are compatible is as follows: 1. Determine the dynamic library files to be compared. 2. Obtain the rpm packages to which the dynamic library files belong in the two systems. 3. Find their corresponding debug packages respectively. 4. Extract the debug files corresponding to the dynamic library in the two debug packages. 5. Use the abicc tool to generate an ABI difference analysis report between the two versions of the dynamic library.

[0115] Correspondingly, the general operation for analyzing whether all ABIs provided by two operating systems are compatible is as follows: 1. In Unix-like systems, the debug files in the software repository are generally also placed in a separate repository. 2. Locate the debug file repositories corresponding to the standard software repositories of the two operating systems. 3. Obtain all the debug file packages of the two operating systems. 4. Use open-source tools (vendors may develop them secondarily according to their needs) to analyze the ABI differences between the two systems. 5. Since ABI differences do not represent all compatibility issues, there are two implicit conditions: (1) This dynamic library must exist in both operating systems. (2) Only the version of this dynamic library can change, and its name, the location of the software package it belongs to, and the location of the repository it belongs to cannot change.

[0116] In the scenario of system migration, not only will the ABI difference data of all dynamic libraries provided by the two operating systems be prepared in advance so that during actual analysis, there is no need to generate it again and it can be directly looked up in a table. Moreover, while collecting data, additional information such as the change situation of the dynamic libraries, the changes in software packages, and the differences in repositories will be supplemented. This data prepared in advance is the so-called data base. The preparation ideas of each vendor are roughly the same, but depending on the software analysis method, there may be different emphases or differences in the focus of data preparation and the specific preparation methods.

[0117] In this method, by pre-preparing a data base for characterizing the differences between the source operating system and the target operating system, the workload of traversing all the software of the source operating system and the target operating system is reduced, the time consumed for compatibility analysis is greatly reduced, and the work efficiency of compatibility analysis is further improved.

[0118] Step S5015: Query the data base, filter out the software packages to be retained in the target operating system, and query the binary files included in the retained software packages.

[0119] In one example, in the case where the rpm package is replaced, there is no need to analyze the compatibility issue. Only the remaining packages will be analyzed for their running compatibility in the target operating system. Figure 6 It is a schematic diagram of finding an elf file to be analyzed according to an embodiment of the present invention, as Figure 6As shown in the figure, finding the ELF files to be analyzed includes: 1. To find the ELF files to be analyzed, a directory can be specified by the user. This directory is the installation directory of the upper-layer application software informed by the user, which is convenient to use as the search scope to find all ELF files.

[0120] 2. At the same time, the user can also specify an RPM package or a TAR package. This package is the installation package of the user's upper-layer business software, and the ELF files can be directly traversed and found from it.

[0121] 3. In addition to the ELF files of the customer's upper-layer business software, it is also necessary to check which system RPM packages have been installed in the customer's source operating system and query the JSON file to determine which RPM packages we will retain. Further query which ELF files are included in these retained RPM packages. Among them, when preparing the data base, analyze whether this package can be directly upgraded (dnf upgrade command) in the repositories of the source and target operating systems. If not, manual configuration is required. Here, the configuration includes corresponding replacements and retention, and the retained part is a JSON record.

[0122] In this method, the binary files of the software to be analyzed are obtained by filtering the installation directories of the application software in the source operating system and the target operating system. The binary files of the software to be analyzed can also be obtained by filtering the application software packages in the source operating system. The binary files of the retained software are obtained by filtering with the data base, realizing the acquisition of the binary files corresponding to all the software that needs to be retained to the target operating system, which is convenient for subsequent compatibility analysis of the software in the target operating system using the binary files.

[0123] Step S502, query the dependency relationship of the binary file. Based on the dependency relationship, judge whether the dependent file on which the binary file depends is a boundary RPM package. For details, please refer to Figure 1 Step S102 of the embodiment shown in the figure, which will not be elaborated here.

[0124] Step S503, when the dependent file on which the binary file depends is not a boundary RPM package, recursively query the dependency relationship of the dependent file until the dependent file is a boundary RPM package. For details, please refer to Figure 1 Step S103 of the embodiment shown in the figure, which will not be elaborated here.

[0125] Step S504, when the dependent file on which the binary file depends is a boundary RPM package, determine that the compatibility of the binary file is consistent with the compatibility of the dependent file. For details, please refer to Figure 1 Step S104 of the embodiment shown in the figure, which will not be elaborated here.

[0126] Step S505, query the ABI interfaces on which the dependent files depend, and determine the compatibility of the software to be analyzed in the target operating system based on the ABI interfaces on which the dependent files depend. For details, please refer to Figure 1 Step S105 of the embodiment shown, which will not be elaborated here.

[0127] The system migration compatibility analysis method provided in this embodiment obtains the binary files of the software to be analyzed by screening the application software installation directories of the source operating system and the target operating system, and can also obtain the binary files of the software to be analyzed by screening the application software packages of the source operating system. The binary files of the retained software are obtained by screening using the data base, realizing the acquisition of the binary files corresponding to all the software that needs to be retained in the target operating system, which is convenient for subsequent compatibility analysis of the software in the target operating system using the binary files. By preparing in advance a data base for characterizing the differences between the source operating system and the target operating system, the workload of traversing all the software of the source operating system and the target operating system is reduced, the time consumed for compatibility analysis is greatly reduced, and the working efficiency of compatibility analysis is further improved.

[0128] In this embodiment, a system migration compatibility analysis method is provided, which can be used for the above computer device. Figure 7 It is a flowchart of another system migration compatibility analysis method according to an embodiment of the present invention, as Figure 7 shown, and this process includes the following steps:

[0129] Step S701, obtain the binary files of the software to be analyzed. For details, please refer to Figure 5 Step S501 of the embodiment shown, which will not be elaborated here.

[0130] Step S702, query the dependency relationship of the binary files, and based on the dependency relationship, judge whether the dependent files on which the binary files depend are boundary rpm packages.

[0131] Specifically, the above step S702 includes:

[0132] Step S7021, query the so library files on which the binary files depend.

[0133] Step S7022, based on the data base, query the rpm packages to which the so library files belong in the target operating system, and judge whether the rpm packages are retained.

[0134] In some optional implementation manners, the above step S7022 includes:

[0135] Step b1, query the data base to obtain the rpm packages in the target operating system corresponding to the rpm packages in the source operating system.

[0136] Step b2: Query the rpm-so correspondence table in the data repository based on the name of the rpm package in the target operating system to determine whether there is an so library corresponding to the rpm package in the target operating system in the target operating system.

[0137] Step b3: When there is no so library corresponding to the rpm package in the target operating system in the target operating system, it is determined that the software to be analyzed is incompatible with the target operating system.

[0138] In one example,

[0139] In this method, by using the pre-constructed data repository, query the rpm package corresponding to the rpm package in the source operating system in the target operating system, query the rpm-so correspondence table in the data repository, and determine whether there is an so library corresponding to the rpm package in the target operating system in the target operating system. When there is no so library corresponding to the rpm package in the target operating system in the target operating system, it is determined that the software to be analyzed is incompatible with the target operating system, reducing the computational effort in the migration evaluation process and further improving the migration efficiency and practical feasibility.

[0140] Step S7023: When the rpm package is not retained, determine that the dependent file on which the binary file depends is the boundary rpm package.

[0141] Step S7024: When the rpm package is retained, determine that the dependent file on which the binary file depends is not the boundary rpm package.

[0142] In one example, Figure 8 is a schematic diagram for analyzing the dependency relationship of elf files according to an embodiment of the present invention. As Figure 8 shown, analyzing the dependency relationship of elf files includes: for each elf file, query the list of so library files on which it depends through the readelf command or the ldd command.

[0143] Query which rpm packages these so libraries on which it depends belong to through the rpm provide command.

[0144] For the found RPM package, check the JSON file to see if this RPM package will be retained. If it is retained, it means that the compatibility of this dependency relationship is guaranteed by the subsequent RPMs. Since the subsequent RPM packages are retained during the migration process, their ELF files must also be in this analysis set. Then this dependency relationship can be skipped. Exemplarily, if it is found that the found RPM package is not retained in the JSON file, it means that this ELF file is a "boundary ELF", and its compatibility depends on whether the target operating system supports it. The JSON file is used to handle RPM packages that cannot be directly upgraded by the system; the upgrade of RPM packages is the main activity. The RPM packages contain SO libraries, and the ELF files contain program files and SO library files. It can be understood that the compatibility of the ELF file depends on the more underlying SO libraries it depends on. Therefore, ELF compatibility -> underlying SO libraries -> replacement situation of SO libraries in the target operating system -> replacement situation of RPM packages -> processing of JSON files.

[0145] Query the name of the RPM package corresponding to the source operating system RPM package in the target operating system in the JSON file, and check whether this entry exists in the RPM-SO correspondence table in the target operating system in the data repository. If it does not exist, it means that this SO library does not exist in the target operating system and cannot provide dependency support, and the corresponding ELF compatibility fails.

[0146] In this method, when the RPM package on which the binary file depends is not retained, recursively analyze until the dependency file on which the binary file depends is a boundary RPM package, and then perform compatibility analysis. Lock the key difference points of the compatibility analysis of the two operating systems after the change in the boundary RPM package, thereby greatly reducing the analysis workload, reducing the computational volume in the migration evaluation link, and then improving the migration efficiency and practical feasibility.

[0147] Step S703, when the dependency file on which the binary file depends is not a boundary RPM package, recursively query the dependency relationship of the dependency file until the dependency file is a boundary RPM package. For details, please refer to Figure 5 Step S503 of the illustrated embodiment, which will not be elaborated here.

[0148] Step S704, when the dependency file on which the binary file depends is a boundary RPM package, determine that the compatibility of the binary file is consistent with the compatibility of the dependency file. For details, please refer to Figure 5 Step S504 of the illustrated embodiment, which will not be elaborated here.

[0149] Step S705, query the ABI interface on which the dependency file depends, and based on the ABI interface on which the dependency file depends, determine the compatibility of the software to be analyzed in the target operating system.

[0150] Specifically, the above step S705 includes:

[0151] Step S7051, when there is a so library corresponding to the rpm package in the target operating system, read the ABI interfaces on which the so library depends.

[0152] Step S7052, query the ABI interface difference table between the source operating system and the target operating system in the data base, and determine whether the ABI interfaces on which the so library depends hit the ABI interface difference table.

[0153] Step S7053, when the ABI interfaces on which the so library depends hit the ABI interface difference table, determine that the software to be analyzed is incompatible with the target operating system.

[0154] Step S7054, when the ABI interfaces on which the so library depends do not hit the ABI interface difference table, determine that the software to be analyzed is compatible with the target operating system.

[0155] In one example, if the rpm-so correspondence table in the target operating system in the data base has this entry, it means that the target operating system has a corresponding so library to support the elf file, but a more fine-grained dependency check - abi analysis needs to be performed. Obtain the set of symbols on which the elf file depends on the so library through readelf - s. Here, the symbol is the ABI information, such as the called functions, data structures, etc. Traverse the symbol list and query the source-target system symbol difference table in the data base. If it hits, it means that although the target operating system provides a new rpm package and so library file, compared with the old version of the so library file, there are incompatible differences in the provided functions and data structures, and the dependencies of the original elf file cannot be supported, that is, the compatibility of this elf fails. If it does not hit, it means that the target operating system provides a new rpm package and a new so file, and the functions and data structures called by the elf file are all outside the differences, that is, the called dependencies are all compatibly supported.

[0156] Figure 9 is a schematic diagram showing the analysis result according to an embodiment of the present invention. As Figure 9 shown, the granularity is coarsened to the rpm package level, and a tree structure of "what the original package is, what packages are currently dependent on, and what packages are replaced in the target operating system" is used to show the compatibility of its dependency relationship, so that users or implementers can see at a glance.

[0157] In this method, when there is a so library corresponding to the rpm package in the target operating system, by using the pre-constructed data base, querying the ABI interface difference table between the source operating system and the target operating system in the data base, it is possible to determine the binary file in a direct table lookup manner, reducing the computational amount in the migration evaluation link and further improving the migration efficiency and practical feasibility.

[0158] For the system migration compatibility analysis method provided in this embodiment, when the rpm package on which the binary file depends is not retained, it is recursively traced until the dependent file on which the binary file depends is the boundary rpm package, and then the compatibility analysis is performed. The key difference points in the compatibility analysis of the two operating systems after the change are locked in the boundary rpm package, thus greatly reducing the analysis workload and the computational amount in the migration evaluation link, and further improving the migration efficiency and practical feasibility. By using the pre-constructed data base, querying the rpm package corresponding to the rpm package in the source operating system in the target operating system, and querying the rpm-so correspondence table in the data base, it is determined whether there is a so library corresponding to the rpm package in the target operating system in the target operating system. When there is no so library corresponding to the rpm package in the target operating system in the target operating system, it is determined that the software to be analyzed is incompatible in the target operating system, reducing the computational amount in the migration evaluation link and further improving the migration efficiency and practical feasibility. When there is a so library corresponding to the rpm package in the target operating system in the target operating system, by using the pre-constructed data base, querying the ABI interface difference table between the source operating system and the target operating system in the data base, it is possible to determine the binary file in a direct table lookup manner, reducing the computational amount in the migration evaluation link and further improving the migration efficiency and practical feasibility.

[0159] In this embodiment, a system migration compatibility analysis device is also provided. This device is used to implement the above-mentioned embodiments and preferred implementation manners, and those that have been described will not be repeated. As used hereinafter, the term "module" can be a combination of software and / or hardware that can implement a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0160] This embodiment provides a system migration compatibility analysis device, as Figure 10 shown, including:

[0161] A file acquisition module 1001, configured to acquire the binary file of the software to be analyzed. For details, please refer to Figure 1 step S101 of the embodiment shown, which will not be repeated here.

[0162] The dependency query module 1002 is used to query the dependencies of a binary file. Based on the dependencies, it determines whether the dependent files on which the binary file depends are boundary RPM packages. The boundary RPM packages are used to represent the binary files that replace the dependent files in the target operating system. For details, please refer to Figure 1 Step S102 of the illustrated embodiment, which will not be elaborated here.

[0163] The recursive query module 1003 is used to recursively query the dependencies of a dependent file when the dependent file on which the binary file depends is not a boundary RPM package until the dependent file is a boundary RPM package. For details, please refer to Figure 1 Step S103 of the illustrated embodiment, which will not be elaborated here.

[0164] The compatibility determination module 1004 is used to determine that the compatibility of the binary file is the same as that of the dependent file when the dependent file on which the binary file depends is a boundary RPM package. For details, please refer to Figure 1 Step S104 of the illustrated embodiment, which will not be elaborated here.

[0165] The ABI analysis module 1005 is used to query the ABI interfaces on which the dependent file depends and determine the compatibility of the software to be analyzed in the target operating system based on the ABI interfaces on which the dependent file depends. For details, please refer to Figure 1 Step S105 of the illustrated embodiment, which will not be elaborated here.

[0166] In some alternative embodiments, the file acquisition module 1001 includes:

[0167] The installation directory acquisition unit is used to acquire the application software installation directory of the source operating system and the application software installation directory of the target operating system.

[0168] The first binary file screening unit is used to screen out the binary files of the software to be analyzed based on the application software installation directory of the source operating system and the application software installation directory of the target operating system.

[0169] And / or, the second binary file screening unit is used to acquire the application software package of the source operating system and screen out the binary files of the software to be analyzed.

[0170] The data base acquisition unit is used to acquire the system software installed in the source operating system and a pre-built data base. The pre-built data base is used to represent the difference data table between the source operating system and the target operating system.

[0171] The third binary file screening unit is used to query the data base, screen out the software packages to be retained in the target operating system, and query the binary files included in the retained software packages.

[0172] In some alternative embodiments, a data base is prepared through the following steps:

[0173] Determine the dynamic library file to be analyzed;

[0174] Obtain the RPM package to which the dynamic library file to be analyzed belongs in the source operating system and the RPM package to which it belongs in the target operating system;

[0175] Based on the RPM package to which the dynamic library file to be analyzed belongs in the source operating system and the RPM package to which it belongs in the target operating system, query and obtain the debug file corresponding to the dynamic library file to be analyzed in the source operating system and the debug file corresponding to the dynamic library file to be analyzed in the target operating system;

[0176] Based on the debug file corresponding to the dynamic library file to be analyzed in the source operating system and the debug file corresponding to the dynamic library file to be analyzed in the target operating system, generate ABI difference data for the dynamic library file to be analyzed to obtain the data base.

[0177] In some alternative embodiments, the dependency query module 1002 includes:

[0178] An So library query unit for querying the So library files on which the binary file depends.

[0179] An RPM package retention judgment unit for querying, based on the data base, the RPM package to which the So library file belongs in the target operating system and judging whether the RPM package is retained.

[0180] A boundary RPM package determination unit for determining, when the RPM package is not retained, the dependent file on which the binary file depends as the boundary RPM package.

[0181] A non-boundary RPM package determination unit for determining, when the RPM package is retained, that the dependent file on which the binary file depends is not a boundary RPM package.

[0182] In some alternative embodiments, the RPM package retention judgment unit includes:

[0183] A data base query subunit for querying the data base to obtain the RPM package in the target operating system corresponding to the RPM package in the source operating system.

[0184] An RPM-So correspondence query subunit for querying the RPM-So correspondence table in the data base based on the name of the RPM package in the target operating system and judging whether there is an So library corresponding to the RPM package in the target operating system in the data base.

[0185] The first system incompatibility determination subunit is used to determine that the software to be analyzed is incompatible with the target operating system when there is no so library corresponding to the rpm package in the target operating system.

[0186] In some optional embodiments, the ABI analysis module 1005 includes:

[0187] The ABI interface reading unit is used to read the ABI interface on which the so library depends when there is a so library corresponding to the rpm package in the target operating system.

[0188] The so library hit judgment unit is used to query the ABI interface difference table between the source operating system and the target operating system in the data base and judge whether the ABI interface on which the so library depends hits the ABI interface difference table.

[0189] The second system incompatibility determination unit is used to determine that the software to be analyzed is incompatible with the target operating system when the ABI interface on which the so library depends hits the ABI interface difference table.

[0190] The system compatibility determination unit is used to determine that the software to be analyzed is compatible with the target operating system when the ABI interface on which the so library depends does not hit the ABI interface difference table.

[0191] The further function descriptions of the above-mentioned various modules and units are the same as those in the corresponding above-mentioned embodiments, and will not be repeated here.

[0192] The system migration compatibility analysis device in this embodiment is presented in the form of functional units. Here, the unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and a memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0193] The embodiment of the present invention also provides a computer device having the above Figure 10 shown system migration compatibility analysis device.

[0194] Please refer to Figure 11 , Figure 11 is a schematic structural diagram of a computer device provided by an optional embodiment of the present invention. As Figure 11As shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. Each component communicates with each other using different buses and can be installed on a common motherboard or installed in other ways as needed. The processor can process instructions executed within the computer device, including instructions stored in the memory or on the memory to display graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In some alternative embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides part of the necessary operations (for example, as a server array, a set of blade servers, or a multi-processor system). Figure 11 Taking one processor 10 as an example in

[0195] The processor 10 can be a central processing unit, a network processor, or a combination thereof. Among them, the processor 10 can further include a hardware chip. The above hardware chip can be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The above programmable logic device can be a complex programmable logic device, a field programmable gate array, a general array logic, or any combination thereof.

[0196] Among them, the memory 20 stores instructions executable by at least one processor 10, so that the at least one processor 10 executes the method shown in the above embodiments.

[0197] The memory 20 can include a program storage area and a data storage area. Among them, the program storage area can store an operating system and application programs required for at least one function; the data storage area can store data created according to the use of the computer device, etc. In addition, the memory 20 can include high-speed random access memory and can also include non-transitory memory, such as at least one disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some alternative embodiments, the memory 20 can optionally include a memory remotely set relative to the processor 10, and these remote memories can be connected to the computer device through a network. Examples of the above network include but are not limited to the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0198] The memory 20 can include volatile memory, such as random access memory; the memory can also include non-volatile memory, such as flash memory, a hard disk, or a solid-state drive; the memory 20 can also include a combination of the above types of memory.

[0199] The computer device further includes an input device 30 and an output device 40. The processor 10, the memory 20, the input device 30, and the output device 40 may be connected by a bus or other means. Figure 11 Taking the connection by bus as an example.

[0200] The input device 30 can receive input digital or character information, and generate key signal inputs related to the user settings and function controls of the computer device, such as a touch screen, a keypad, a mouse, a trackpad, a touchpad, a pointing stick, one or more mouse buttons, a trackball, a joystick, etc. The output device 40 may include a display device, an auxiliary lighting device (e.g., an LED), and a haptic feedback device (e.g., a vibration motor), etc. The above display device includes, but is not limited to, a liquid crystal display, a light-emitting diode, a display, and a plasma display. In some alternative embodiments, the display device may be a touch screen.

[0201] The embodiment of the present invention also provides a computer-readable storage medium. The method according to the embodiment of the present invention can be implemented in hardware, firmware, or be implemented as computer code that can be recorded on a storage medium, or be implemented as computer code that is originally stored in a remote storage medium or a non-transitory machine-readable storage medium and downloaded through a network and will be stored in a local storage medium, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disc, a read-only memory, a random access memory, a flash memory, a hard disk, or a solid-state drive, etc.; further, the storage medium may also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by the computer, the processor, or the hardware, the method shown in the above embodiments is implemented.

[0202] A part of the present invention can be applied as a computer program product, such as computer program instructions. When executed by a computer, through the operation of the computer, the methods and / or technical solutions according to the present invention can be called or provided. Those skilled in the art should be able to understand that the forms of existence of computer program instructions in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executes the instructions, or the computer compiles the instructions and then executes the corresponding compiled program, or the computer reads and executes the instructions, or the computer reads and installs the instructions and then executes the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible by the computer.

[0203] Although embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A system migration compatibility analysis method, characterized in that The method includes: Obtain the binary file of the software to be analyzed; Query the dependency relationship of the binary file, and based on the dependency relationship, determine whether the dependent file on which the binary file depends is a boundary rpm package, where the boundary rpm package is used to represent the binary file replaced by the dependent file in the target operating system; When the dependent file on which the binary file depends is not a boundary rpm package, recursively query the dependency relationship of the dependent file until the dependent file is a boundary rpm package; When the dependent file on which the binary file depends is a boundary rpm package, determine that the compatibility of the binary file is consistent with the compatibility of the dependent file; Query the ABI interface on which the dependent file depends, and based on the ABI interface on which the dependent file depends, determine the compatibility of the software to be analyzed in the target operating system; Among them, the querying the ABI interface on which the dependent file depends and determining the compatibility of the software to be analyzed in the target operating system based on the ABI interface on which the dependent file depends includes: When there is an so library corresponding to the rpm package in the target operating system, read the ABI interface on which the so library depends; Query the ABI interface difference table between the source operating system and the target operating system in the data base, and determine whether the ABI interface on which the so library depends hits the ABI interface difference table, where the data base is pre-constructed, and the pre-constructed data base is used to represent the difference data table between the source operating system and the target operating system; When the ABI interface on which the so library depends hits the ABI interface difference table, determine that the software to be analyzed is incompatible in the target operating system; When the ABI interface on which the so library depends does not hit the ABI interface difference table, determine that the software to be analyzed is compatible in the target operating system.

2. The method according to claim 1, wherein The obtaining the binary file of the software to be analyzed includes: Obtain the application software installation directory of the source operating system and the application software installation directory of the target operating system; Based on the application software installation directory of the source operating system and the application software installation directory of the target operating system, screen and obtain the binary file of the software to be analyzed; And / or, obtain the application software package of the source operating system, and screen and obtain the binary file of the software to be analyzed; Obtain the system software installed in the source operating system and the pre-constructed data base; Query the data base, screen and obtain the software packages to be retained in the target operating system, and query the binary files included in the retained software packages.

3. The method according to claim 2, wherein The data base is prepared through the following steps: Determine the dynamic library file to be analyzed; Obtain the rpm package to which the dynamic library file to be analyzed belongs in the source operating system and the rpm package to which the dynamic library file to be analyzed belongs in the target operating system; Based on the rpm package to which the dynamic library file to be analyzed belongs in the source operating system and the rpm package to which the dynamic library file to be analyzed belongs in the target operating system, query and obtain the debug file corresponding to the dynamic library file to be analyzed in the source operating system and the debug file corresponding to the dynamic library file to be analyzed in the target operating system; Generate the ABI difference data of the dynamic library file to be analyzed based on the debug file corresponding to the dynamic library file to be analyzed in the source operating system and the debug file corresponding to the dynamic library file to be analyzed in the target operating system, and obtain the data base.

4. The method according to claim 2, wherein Query the dependency relationship of the binary file, and based on the dependency relationship, determine whether the dependent file on which the binary file depends is a boundary rpm package, including: Query the so library file on which the binary file depends; Based on the data base, query the rpm package to which the so library file belongs in the target operating system, and determine whether the rpm package is retained; When the rpm package is not retained, determine that the dependent file on which the binary file depends is a boundary rpm package; When the rpm package is retained, determine that the dependent file on which the binary file depends is not a boundary rpm package.

5. The method according to claim 4, wherein The querying, based on the data base, the rpm package to which the so library file belongs in the target operating system includes: Query the data base to obtain the rpm package corresponding to the rpm package in the source operating system in the target operating system; Based on the name of the rpm package in the target operating system, query the rpm-so correspondence table in the data base to determine whether there is an so library corresponding to the rpm package in the target operating system; When there is no so library corresponding to the rpm package in the target operating system in the target operating system, determine that the software to be analyzed is incompatible in the target operating system.

6. A system migration compatibility analysis device, characterized in that, The device includes: A file acquisition module for acquiring the binary file of the software to be analyzed; A dependency relationship query module for querying the dependency relationship of the binary file, and based on the dependency relationship, determining whether the dependent file on which the binary file depends is a boundary rpm package, where the boundary rpm package is used to represent the binary file whose dependent file is replaced in the target operating system; A recursive query module for recursively querying the dependency relationship of the dependent file when the dependent file on which the binary file depends is not a boundary rpm package until the dependent file is a boundary rpm package; A compatibility determination module for determining that the compatibility of the binary file is the same as the compatibility of the dependent file when the dependent file on which the binary file depends is a boundary rpm package; An ABI analysis module for querying the ABI interface on which the dependent file depends, and based on the ABI interface on which the dependent file depends, determining the compatibility of the software to be analyzed in the target operating system; Among them, the ABI analysis module is specifically configured to: when there is a so library corresponding to the rpm package in the target operating system, read the ABI interfaces on which the so library depends; query the ABI interface difference table between the source operating system and the target operating system in the data base, and determine whether the ABI interfaces on which the so library depends hit the ABI interface difference table, where the data base is pre-built and the pre-built data base is used to represent the difference data table between the source operating system and the target operating system; when the ABI interfaces on which the so library depends hit the ABI interface difference table, determine that the software to be analyzed is incompatible with the target operating system; when the ABI interfaces on which the so library depends do not hit the ABI interface difference table, determine that the software to be analyzed is compatible with the target operating system.

7. A computer device, characterized in that, Comprising: A memory and a processor, the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to execute the system migration compatibility analysis method according to any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, Computer instructions are stored on the computer-readable storage medium, and the computer instructions are used to cause a computer to execute the system migration compatibility analysis method according to any one of claims 1 to 5.

9. A computer program product, characterized in that, Comprising computer instructions, the computer instructions are used to cause a computer to execute the system migration compatibility analysis method according to any one of claims 1 to 5.

Images