System migration compatibility analysis method and device, computer equipment and storage medium

Abstract

The invention relates to the technical field of system migration, and discloses a system migration compatibility analysis method and device, computer equipment and a storage medium, and the method comprises the steps: obtaining a binary file of to-be-analyzed software; querying a dependency relationship of the binary file, and judging whether a dependent file on which the binary file depends is a boundary rpm package or not; when the dependent file depended by the binary file is not the boundary rpm package, recursively querying the dependency relationship of the dependent file until the dependent file is the boundary rpm package; and when the dependent file on which the binary file depends is the boundary rpm package, querying the ABI interface on which the dependent file depends, and determining the compatibility of the to-be-analyzed software in the target operating system based on the ABI interface on which the dependent file depends. According to the method, compatibility difference is changed into a boundary rpm package from all existing reserved files, performance consumption and implementation difficulty of migration analysis are reduced, and migration efficiency and practical feasibility are improved to a great extent.

Description

Technical Field

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

[0002] The server operating system used by enterprise users has a continuous maintenance requirement, and the maintenance cycle of the operating system is generally about 5 years. After the expiration, customers will face the need to change to a new operating system. However, at this time, the business software and business data themselves often have characteristics such as long development cycle, 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 this environment, customers will require the system migration implementer to change the operating system in an "in-place migration" manner, that is, to keep the original hardware platform or virtual hardware platform and upper-level 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 technology, major system manufacturers mostly adopt the "on-site migration" solution, and the implementation methods are similar. Without reinstalling the operating system, the underlying components of the system are replaced and the kernel module is reloaded to achieve the goal of minimizing the technical threshold of customers to complete the operating system change. In the implementation process of "on-site migration", a new problem will be introduced: the replacement of software by the operating system before and after the migration is not a smooth replacement, that is, there must be some software packages in the system before the migration, and there are no corresponding replacement components in the system after the migration. In addition, some packages in the original system are dependent on the user's upper-level software, and the target operating system may also provide corresponding packages, but they are not compatible with the support interface of the upper-level software. The existing compatibility analysis of the migration system requires traversing all software packages and corresponding dependent software. The compatibility analysis is time-consuming and 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 system migration compatibility analysis method, apparatus, computer equipment and storage medium to solve the problem that the existing compatibility analysis is time-consuming and inefficient.

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

[0006] Get 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 that the binary file depends on 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;

[0008] When the dependent file that the binary file depends on is not a boundary rpm package, the dependency relationship of the dependent file is recursively queried until the dependent file is a boundary rpm package;

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

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

[0011] In the present invention, starting from the difference between the software warehouse after the change and the software already installed in the system after the two operating systems are changed, the dependency relationship of the binary files in the software to be analyzed is queried, the boundary rpm package is pre-searched, and the compatibility of the binary file is determined to depend on the dependent file, and it is judged whether the dependent file is a boundary rpm package. When the dependent file that the binary file depends on is not a boundary rpm package, the compatibility analysis is performed again recursively until the dependent file that the binary file depends on is a boundary rpm package. The comparison operation domain of the compatibility difference is changed from analyzing the compatibility of all retained files in the prior art to only analyzing the compatibility of the boundary rpm package, so that the compatibility of all retained files can be determined, which greatly reduces the workload of analysis, reduces the performance consumption and implementation difficulty of migration analysis, and greatly improves the migration efficiency and practical feasibility.

[0012] In an optional implementation, obtaining a binary file 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, the binary file of the software to be analyzed is obtained by screening;

[0015] and / or, obtaining an application software package of a source operating system and screening to obtain a binary file of the software to be analyzed;

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

[0017] The data base is queried to filter out the software packages reserved in the target operating system, and the binary files contained in the reserved software packages are queried.

[0018] In this method, the binary files of the software to be analyzed are obtained by filtering out the application software installation directories of the source operating system and the target operating system. The binary files of the software to be analyzed can also be filtered out through the application software packages of the source operating system. The binary files of the retained software are filtered out using the data base, thereby achieving the acquisition of the binary files corresponding to all the software that needs to be retained in the target operating system, which facilitates the subsequent use of binary files to perform compatibility analysis of the software on the target operating system.

[0019] In an optional embodiment, the data base is prepared by 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 the dynamic library file to be analyzed belongs in the target operating system, query and obtain the debugging file corresponding to the dynamic library file to be analyzed in the source operating system and the debugging file corresponding to the dynamic library file to be analyzed in the target operating system;

[0023] Based on the debugging file corresponding to the dynamic library file to be analyzed in the source operating system and the debugging file corresponding to the dynamic library file to be analyzed in the target operating system, ABI difference data of the dynamic library file to be analyzed is generated to obtain a 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 software of the source operating system and the target operating system is reduced, the time spent on compatibility analysis is greatly reduced, and the work efficiency of compatibility analysis is further improved.

[0025] In an optional implementation, querying the dependency relationship of the binary file, and judging whether the dependent file that the binary file depends on is a boundary rpm package based on the dependency relationship, includes:

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

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

[0028] When the rpm package is not retained, the dependent files that the binary file depends on are determined to be boundary rpm packages;

[0029] When the rpm package is reserved, determine the dependent files that the binary file depends on and the non-boundary rpm package.

[0030] In this method, when the rpm package that the binary file depends on is not retained, the compatibility analysis is performed recursively until the dependent file that the binary file depends on is a boundary rpm package. The key difference points of the compatibility analysis of the two operating systems after the change are locked in the boundary rpm package, thereby greatly reducing the workload of analysis and the amount of calculation in the migration evaluation link, thereby improving the migration efficiency and practical feasibility.

[0031] In an optional implementation, based on the data base, querying the rpm package to which the so library file belongs in the target operating system includes:

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

[0033] 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 a so library corresponding to the rpm package in the target operating system in the target operating system;

[0034] When the target operating system does not have the so library corresponding to the rpm package in the target operating system, it is determined that the software to be analyzed is incompatible with the target operating system.

[0035] In this method, by utilizing the pre-built data base, the rpm package in the source operating system is queried to correspond to the rpm package in the target operating system, and the data base rpm-so correspondence table is queried to determine whether there is a so library in the target operating system corresponding to the rpm package in the target operating system. When the so library corresponding to the rpm package in the target operating system does not exist in the target operating system, it is determined that the software to be analyzed is incompatible with the target operating system, which reduces the amount of calculation in the migration evaluation link and further improves the migration efficiency and practical feasibility.

[0036] In an optional implementation, querying the ABI interface that the dependent file depends on, and determining the compatibility of the software to be analyzed in the target operating system based on the ABI interface that the dependent file depends on, includes:

[0037] When the target operating system has a so library corresponding to the rpm package in the target operating system, read the ABI interface that the so library depends on;

[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 interface that the so library depends on hits the ABI interface difference table;

[0039] When the ABI interface that the so library depends on hits the ABI interface difference table, it is determined that the software to be analyzed is incompatible with the target operating system;

[0040] When the ABI interface that the so library depends on does not hit 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 in the target operating system, by utilizing the pre-built data base, the ABI interface difference table between the source operating system and the target operating system in the data base is queried, so that the binary file can be determined by directly looking up the table, reducing the amount of calculation 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, the device comprising:

[0043] A file acquisition module, used to obtain the binary file of the software to be analyzed;

[0044] A dependency query module is used to query the dependency of binary files, and based on the dependency, determine whether the dependent file that the binary file depends on is a boundary rpm package, and the boundary rpm package is used to represent the binary file whose dependent file is replaced in the target operating system;

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

[0046] A compatibility determination module, used for determining that the compatibility of the binary file is consistent with the compatibility of the dependent file when the dependent file that the binary file depends on is a boundary rpm package;

[0047] The ABI analysis module is used to query the ABI interface that the dependent file depends on, and determine the compatibility of the software to be analyzed in the target operating system based on the ABI interface that the dependent file depends on.

[0048] In a third aspect, the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the system migration compatibility analysis method of the first aspect or any corresponding embodiment thereof by executing the computer instructions.

[0049] In a fourth aspect, the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the system migration compatibility analysis method of the first aspect or any corresponding embodiment thereof.

[0050] In a fifth aspect, the present invention provides a computer program product, comprising computer instructions for causing a computer to execute the system migration compatibility analysis method of the first aspect or any corresponding embodiment thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

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

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

[0054] Figure 3 It is a schematic diagram of an example of a boundary rpm when a source-destination operating system is changed according to an embodiment of the present invention.

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

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

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

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

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

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

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

[0062] Fig.11 It is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0063] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0064] In the related technology, major system manufacturers mostly adopt the "on-site migration" solution, and the implementation methods are similar. Without reinstalling the operating system, the underlying components of the system are replaced and the kernel module is reloaded to achieve the goal of minimizing the technical threshold of customers to complete the operating system change. In the implementation process of "on-site migration", a new problem will be introduced: the replacement of software by the operating system before and after the migration is not a smooth replacement, that is, there must be some software packages in the system before the migration, and there are no corresponding replacement components in the system after the migration. In addition, some packages in the original system are dependent on the user's upper-level software, and the target operating system may also provide corresponding packages, but they are not compatible with the support interface of the upper-level software. The existing compatibility analysis of the migration system requires traversing all software packages and corresponding dependent software. The compatibility analysis is time-consuming and inefficient, resulting in unsatisfactory efficiency and practical feasibility of the migration method.

[0065] To solve the problem of whether the application software can run compatibly in the new system, the existing technology uses virtual environment simulation, such as: CN117555876A is a simulation operation method based on a virtual file system. However, this method requires customers to have an accurate understanding of the deployment, operation, and maintenance of their own business software. In reality, customers focus on how to operate their own business and are familiar with the "business tools" they use. This is really difficult to ask, which is also a pain point in the current migration work industry.

[0066] There are also evaluation methods based on the compatibility of the operating system basic suite, such as: CN115469928A. However, there are still a few application software that directly use the basic suite to run their own business logic, or only scripted programs will do so, while compiled programs often directly call the system basic library symbols to interact with the operating system and efficiently complete their own functions. This type of software is often industrial-grade business software used by enterprises, and its compatibility must start with the basic library symbols provided by the operating system it relies on.

[0067] In order to solve the above problems, a system migration compatibility analysis method is provided in an embodiment of the present invention, which is used in a computer device. It should be noted that its 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 software and hardware. 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 embodiment of the present application can be a smart phone, a personal computer, a tablet computer, or other intelligent hardware devices. In the following method embodiments, the execution subject is a computer device as an example for explanation.

[0068] The computer device in this embodiment is suitable for use scenarios in which the compatibility of the upper-layer application software version and the business configuration in the new system environment is analyzed when the original hardware platform or virtual hardware platform and the upper-layer business application are kept unchanged and only the components provided by the operating system are replaced. The system migration compatibility analysis method provided by the present invention starts from the difference between the software warehouse after the change of the two operating systems and the software installed by the system, queries the dependency relationship of the binary files in the software to be analyzed, searches for the boundary rpm package in advance, determines that the compatibility of the binary file depends on the dependent file, determines whether the dependent file is a boundary rpm package, and recursively performs compatibility analysis when the dependent file that the binary file depends on is not a boundary rpm package, and changes the compatibility difference comparison operation domain from the prior art of analyzing the compatibility of all retained files to only analyzing the compatibility of the boundary rpm package, so that the compatibility of all retained files can be determined, which greatly reduces the workload of analysis, reduces the performance consumption and implementation difficulty of migration analysis, and greatly improves 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 a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown 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 flow chart of a system migration compatibility analysis method according to an embodiment of the present invention. Figure 1 As shown, the process includes the following steps:

[0071] Step S101, obtaining the binary file of the software to be analyzed.

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

[0073] Step S102, querying the dependency relationship of the binary file, and based on the dependency relationship, determining whether the dependent file that the binary file depends on is a boundary rpm package.

[0074] In the embodiment of the present invention, the boundary rpm package is used to represent a binary file whose dependent files are replaced in the target operating system.

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

[0076] Step S103, when the dependent file that the binary file depends on 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 that the upper-layer binary file depends on has a next layer, and its next-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.

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

[0079] In one example, if the rpm package that the upper-layer binary file depends on 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 the so library file it depends on, and whether there is corresponding so library support in the target operating system.

[0080] Step S105, querying the ABI interface that the dependent file depends on, and determining the compatibility of the software to be analyzed in the target operating system based on the ABI interface that the dependent file depends on.

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

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

[0083] In one implementation scenario, the process of operating system in-place migration is essentially divided into three parts: 1) Check the basic packages of 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 warehouse source used by the source operating system with the software warehouse source of the target operating system. 3) Perform compatibility dependency analysis on the upper-layer software in the source operating system that cannot be replaced, and take measures such as retention, deletion, or avoidance based on the analysis results.

[0084] In the system migration scenario, if the system meets the following ideal conditions: 1. The two operating systems have little difference in software warehouse architecture organization; 2. The two operating systems mostly update their software in the form of version updates, and do not involve package merging, splitting, renaming, or abandonment. At this time, the conventional practice is to only configure the system's software warehouse address to the target operating system's warehouse address, and then use the system's dnf software management tool to perform the upgrade operation (the command is dnfupgrade). At this time, the software management tool will automatically determine which upgradeable packages of the software components installed in the current system are in the new warehouse, and perform the upgrade operation.

[0085] However, the actual situation of system migration is often a system change scenario across different manufacturers and major versions. When using the same operation, the following situations may occur: 1. The organizational structure of the software warehouse of the two systems is inconsistent. 2. The same package undergoes major changes during a major version update, and the rpm package is split, merged, renamed, abandoned, or the location of the warehouse to which it belongs is changed in the new version. In this case, the system's software management tool cannot find the available update components for the software in the new warehouse. No matter how it is handled, there will inevitably be a part of the source operating system software packages that cannot be directly found in the target operating system. Replacement components are retained. There are three situations:

[0086] 1. Full operating system change model: compare all software in all standard repositories of the source operating system and the target operating system. This model determines the upper boundary of the compatibility analysis. Taking the migration of the centos7 operating system to the ChangQing 24 operating system as an example, its standard repositories are: base library, update library, and extras warehouse. The standard warehouse of the ChangQing 24 system is unified as: everything warehouse. Then fully analyze the difference between the two, and through comparison, determine what operations the rpm package in the source operating system should take in the target operating system, and record it in the implementation configuration file of the migration tool to guide its behavior (behavior includes: how to change packages: replace, merge, split, rename, change warehouse, discard, etc., which are not limited in the present invention). Compare and prepare the data base based on the full analysis domain. The amount of software packages encountered in the actual user operating system environment is less than the data base, that is, the software that the user actually needs to analyze is a subset of the provisioned data base. It provides a source and theoretical basis for the provision of the data base, corresponding to the above Figure 2 The first part of .

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

[0088] 3. Migration model considering customer business applications and actual dependencies: Figure 3 1 is a schematic diagram of an example of a boundary rpm when a source and destination operating system is changed according to an embodiment of the present invention. Figure 3 As shown in the figure, the software in the actual customer environment consists of the following parts: the software packages provided by the source operating system basic yum source, which are installed in the customer environment and will be replaced by the corresponding package group of the long engine in the json file ( Figure 3 The part in the solid line box); found in the source operating system, but the json file will keep the part ( Figure 3 The reserved parts are divided into the following categories:

[0089] 1) It is the source operating system yum source, but due to "merger, rename, abandonment, dependency, etc.", the json file is retained.

[0090] 2) It is not a system yum source, but a package installed by the customer to meet the needs of upper-level business.

[0091] During the migration process, the elf file is actually used to infer the rpm package to which the elf file belongs, and the rpm package is used as the unit of change. Therefore, the rpm package is used as an example in the figure.

[0092] Before the system migration process, customer business can run normally, and the dependencies and compatibility of software packages within the source operating system can be "self-consistent".

[0093] During the system migration process, the discovered source operating system warehouse package is replaced by json, and the replaced target operating system rpm package part is self-consistent (the part in the solid line box in the figure).

[0094] After the system migration process, the rpm package retained by the source operating system (the dotted box in the figure) may not have internal dependencies and compatibility, for the following reasons:

[0095] If the rpm package that the upper-level package depends on has no dependencies on the next level, it can be self-consistent.

[0096] If the rpm package that the upper-level package depends on is replaced, the compatibility of this package needs to be analyzed - it is classified as a boundary rpm package (the bold dashed part in the figure). The compatibility of this package depends on the so library file it depends on, and whether there is a corresponding so library support in the target operating system (the bold solid line part in the figure).

[0097] If the rpm package that the upper-layer package depends on has a lower layer, and its 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 is a schematic diagram of a recursive logic for analyzing and preserving software compatibility according to an embodiment of the present invention, such as Figure 4 As shown, let the compatibility of the boundary elf be elf0, and the compatibility of a certain elf be elf n , the compatibility of the binary file that an elf directly depends on is elf n-1 , the recursive formula of the dependency is as follows:

[0098]

[0099] The compatibility of many upper-level elf files in the target operating system can be directly attributed to the "compatibility of boundary elf".

[0100] The system migration compatibility analysis method provided in the present embodiment starts from the difference between the software warehouse after the change and the software installed in the system after the change of two operating systems, queries the dependency relationship of the binary files in the software to be analyzed, searches for the boundary rpm package in advance, determines that the compatibility of the binary file depends on the dependent file, judges whether the dependent file is a boundary rpm package, and performs compatibility analysis when the dependent file that the binary file depends on is not a boundary rpm package, recursively until the dependent file that the binary file depends on is a boundary rpm package, and changes the operation domain of the comparison of compatibility differences from analyzing the compatibility of all retained files in the prior art to only analyzing the compatibility of the boundary rpm package, so that the compatibility of all retained files can be determined, which greatly reduces the workload of analysis, reduces the performance consumption and implementation difficulty of migration analysis, and greatly improves 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 5FIG. 1 is a flow chart of another system migration compatibility analysis method according to an embodiment of the present invention. Figure 5 As shown, the process includes the following steps:

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

[0103] Specifically, the above step S501 includes:

[0104] Step S5011, obtaining 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, filter and obtain the binary file of the software to be analyzed.

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

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

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

[0109] In some optional embodiments, the data base is prepared by the following steps:

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

[0111] Step a2, obtaining 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.

[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 debugging file corresponding to the dynamic library file to be analyzed in the source operating system and the debugging file corresponding to the dynamic library file to be analyzed in the target operating system.

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

[0114] In one example, the conventional approach to analyzing whether the ABI of a dynamic library provided by two operating systems is compatible is: 1. Determine the dynamic library file to be compared. 2. Obtain the rpm packages to which the dynamic library file belongs in the two systems. 3. Find the corresponding debugging packages respectively. 4. Take out the debugging files corresponding to the dynamic library in the two debugging packages. 5. Use the abicc tool to generate an ABI difference analysis report between the two versions of the dynamic library.

[0115] Correspondingly, the normal operation method for analyzing whether all ABIs provided by two operating systems are compatible is: 1. In Unix-like systems, the debugging files in the software warehouse are generally placed in a separate warehouse. 2. Find the debugging file warehouse corresponding to the standard software warehouse of the two operating systems. 3. Obtain all the debugging file packages of the two operating systems. 4. Use open source tools (the manufacturer may develop them according to needs) to analyze the ABI differences between the two systems. 5. Because ABI differences cannot represent full compatibility issues, two conditions are implied: (1) This dynamic library must exist in both operating systems. (2) This dynamic library only has version changes, and the name, location of the software package to which it belongs, and the location of the warehouse to which it belongs cannot change.

[0116] In the scenario of system migration, not only the ABI difference data of all dynamic libraries provided by the two operating systems are often prepared in advance, so that in actual analysis, there is no need to generate them again, and you can directly look up the table. In addition, while collecting data, additional information will be added on the changes in dynamic libraries, changes in software packages, differences in warehouses, etc. This data prepared in advance is the so-called data base. The ideas of preparation by various manufacturers are similar, but depending on the different software analysis methods, there may be different emphases or differences in the focus of data preparation and specific methods of preparation.

[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 software of the source operating system and the target operating system is reduced, the time spent on compatibility analysis is greatly reduced, and the work efficiency of compatibility analysis is further improved.

[0118] Step S5015, query the data base, filter and obtain the software packages reserved in the target operating system, and query the binary files contained in the reserved software packages.

[0119] In one example, since the rpm package is replaced, there is no need to analyze the compatibility issue, and only the remaining package will be analyzed for its running compatibility in the target operating system. Figure 6 is a schematic diagram of searching for an elf file to be analyzed according to an embodiment of the present invention, such as Figure 6As shown, searching for the elf file to be analyzed includes: 1. Searching for the elf file to be analyzed can be done by setting a directory by the user. This directory is the installation directory of the upper application software informed by the user, so that all elf files can be found by using this as the search range.

[0120] 2. At the same time, you can also specify an rpm package or tar package through the user. This package is the installation package of the user's upper-level business software, and directly traverse and search for elf files from it.

[0121] 3. In addition to the elf files of the customer's upper-level business software, we also need to determine 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. These retained rpm packages are further queried to see which elf files are contained in them. When preparing the data base, analyze whether this package can be directly upgraded (dnfupgrade command) in the warehouse of the source and destination operating systems. If not, manual configuration is required. The configuration here includes corresponding replacement and retention, and the retained part is the json record.

[0122] In this method, the binary files of the software to be analyzed are obtained by filtering out the application software installation directories of the source operating system and the target operating system. The binary files of the software to be analyzed can also be filtered out through the application software packages of the source operating system. The binary files of the retained software are filtered out using the data base, thereby achieving the acquisition of the binary files corresponding to all the software that needs to be retained in the target operating system, which facilitates the subsequent use of binary files to perform compatibility analysis of the software on the target operating system.

[0123] Step S502, query the dependency relationship of the binary file, and based on the dependency relationship, determine whether the dependent file that the binary file depends on is a boundary rpm package. Figure 1 Step S102 of the illustrated embodiment will not be described in detail here.

[0124] Step S503: When the dependent file that the binary file depends on is not a boundary rpm package, recursively query the dependency relationship of the dependent file until the dependent file is a boundary rpm package. Figure 1 Step S103 of the illustrated embodiment will not be described in detail here.

[0125] Step S504: When the dependent file that the binary file depends on is a boundary rpm package, determine that the compatibility of the binary file is consistent with the compatibility of the dependent file. Figure 1 Step S104 of the illustrated embodiment will not be described in detail here.

[0126] Step S505, query the ABI interface that the dependent file depends on, and determine the compatibility of the software to be analyzed in the target operating system based on the ABI interface that the dependent file depends on. Figure 1 Step S105 of the illustrated embodiment will not be described in detail here.

[0127] The system migration compatibility analysis method provided in this embodiment obtains the binary files of the software to be analyzed by filtering 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 filtering the application software packages of the source operating system, and obtain the binary files of the retained software by filtering the data base, thereby achieving 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 the subsequent use of binary files to perform compatibility analysis of the software in the target operating system. 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 spent on compatibility analysis is greatly reduced, and the work 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-mentioned computer device. Figure 7 is a flowchart of another system migration compatibility analysis method according to an embodiment of the present invention. Figure 7 As shown, the process includes the following steps:

[0129] Step S701, obtain the binary file of the software to be analyzed. Figure 5 Step S501 of the illustrated embodiment will not be described in detail here.

[0130] Step S702, querying the dependency relationship of the binary file, and based on the dependency relationship, determining whether the dependent file that the binary file depends on is a boundary rpm package.

[0131] Specifically, the above step S702 includes:

[0132] Step S7021, query the so library file that the binary file depends on.

[0133] Step S7022, based on the data base, query the rpm package to which the so library file belongs in the target operating system to determine whether the rpm package is retained.

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

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

[0136] Step b2, 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 a so library corresponding to the rpm package in the target operating system.

[0137] Step b3: When the target operating system does not have a so library corresponding to the rpm package 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 utilizing the pre-built data base, the rpm package in the source operating system is queried to correspond to the rpm package in the target operating system, and the data base rpm-so correspondence table is queried to determine whether there is a so library in the target operating system corresponding to the rpm package in the target operating system. When the so library corresponding to the rpm package in the target operating system does not exist in the target operating system, it is determined that the software to be analyzed is incompatible with the target operating system, which reduces the amount of calculation in the migration evaluation link and further improves 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 a boundary rpm package.

[0141] Step S7024, when the rpm package is retained, determine the dependent file non-boundary rpm package that the binary file depends on.

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

[0143] Use the rpm provide command to query which rpm packages these dependent so libraries belong to.

[0144] For the found rpm package, check the json file to see if the rpm package will be retained. If it is retained, the compatibility of this dependency is guaranteed by the subsequent rpm, because the subsequent rpm package is retained during the migration process, so its elf file must also be in this analysis set. Then this dependency can be skipped. For example, if the json file is not retained for the found rpm package, it means that the elf file is a "boundary elf", and its compatibility depends on whether the target operating system supports it. Json files are used to process rpm packages that cannot be directly upgraded by the system; the upgrade of Rpm packages is the main activity, and the rpm package contains so libraries. The elf file has program files and so library files. It can be understood that the compatibility of the elf file depends on the lower-level so library it depends on. Therefore, elf compatibility->lower-level so library->target operating system so library replacement->rpm package replacement-->json file processing.

[0145] Query the name of the target operating system rpm package corresponding to the source operating system rpm package in the json file, and query whether the entry exists in the rpm-so corresponding relationship table in the target operating system in the data base. If not, it means that the so library does not exist in the target operating system and cannot provide dependency support. The corresponding elf compatibility fails.

[0146] In this method, when the rpm package that the binary file depends on is not retained, the compatibility analysis is performed recursively until the dependent file that the binary file depends on is a boundary rpm package. The key difference points of the compatibility analysis of the two operating systems after the change are locked in the boundary rpm package, thereby greatly reducing the workload of analysis and the amount of calculation in the migration evaluation link, thereby improving the migration efficiency and practical feasibility.

[0147] Step S703: When the dependent file that the binary file depends on is not a boundary rpm package, recursively query the dependency relationship of the dependent file until the dependent file is a boundary rpm package. Figure 5 Step S503 of the illustrated embodiment will not be described in detail here.

[0148] Step S704: When the dependent file that the binary file depends on is a boundary rpm package, determine that the compatibility of the binary file is consistent with the compatibility of the dependent file. Figure 5 Step S504 of the illustrated embodiment will not be described in detail here.

[0149] Step S705, querying the ABI interface that the dependent file depends on, and determining the compatibility of the software to be analyzed in the target operating system based on the ABI interface that the dependent file depends on.

[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 in the target operating system, read the ABI interface that the so library depends on.

[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 interface that the so library depends on hits the ABI interface difference table.

[0153] Step S7053: When the ABI interface that the so library depends on hits the ABI interface difference table, it is determined that the software to be analyzed is incompatible with the target operating system.

[0154] Step S7054: when the ABI interface that the so library depends on does not hit the ABI interface difference table, it is determined that the software to be analyzed is compatible with the target operating system.

[0155] In one example, if the entry exists in the rpm-so correspondence table in the target operating system in the data base, it means that the target operating system has a corresponding so library to support the elf file, but a more fine-grained dependency check, namely abi analysis, is required. Use readelf-s to obtain the set of symbols that the elf file depends on the so library. The symbol here is the ABI information, such as the called functions and data structures. Traverse the symbol list and query the source system symbol difference table in the data base. If it is a hit, it means that although the target operating system provides a new rpm package and so library file, there are incompatible differences in the functions and data structures provided compared to the old version of the so library file, and the original elf file dependency cannot be supported, that is, the compatibility of the elf file is not passed. If it is not a 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 difference, that is, the called dependencies are compatible and supported.

[0156] Fig. 9 is a schematic diagram showing analysis results according to an embodiment of the present invention, such as Fig. 9 As shown, the granularity is coarsened to the rpm package level, and a tree structure of "original package, current dependent packages, and replaced packages of the target operating system" is used to show the compatibility of its dependencies so that users or implementers can see it at a glance.

[0157] In this method, when there is an so library corresponding to the rpm package in the target operating system in the target operating system, by utilizing the pre-built data base, the ABI interface difference table between the source operating system and the target operating system in the data base is queried, so that the binary file can be determined by directly looking up the table, reducing the amount of calculation in the migration evaluation link, and further improving the migration efficiency and practical feasibility.

[0158] The system migration compatibility analysis method provided in this embodiment, when the rpm package that the binary file depends on is not retained, recursively until the dependent file that the binary file depends on is a boundary rpm package, and then performs compatibility analysis, the key difference point of the compatibility analysis of the two operating systems after the change is locked in the boundary rpm package, thereby greatly reducing the workload of the analysis, reducing the amount of calculation in the link of migration evaluation, and thus improving the migration efficiency and practical feasibility. By using the pre-built data base, querying the rpm package in the source operating system corresponding to the rpm package in the target operating system, querying the data base rpm-so correspondence table, judging 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 with the target operating system, reducing the amount of calculation in the link of migration evaluation, 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-built 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 by directly looking up the table, reducing the amount of calculation in the link of migration evaluation, and further improving the migration efficiency and practical feasibility.

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

[0160] This embodiment provides a system migration compatibility analysis device, such as Fig.10 As shown, including:

[0161] The file acquisition module 1001 is used to acquire the binary file of the software to be analyzed. Figure 1 Step S101 of the illustrated embodiment will not be described in detail here.

[0162] The dependency query module 1002 is used to query the dependency of the binary file, and based on the dependency, determine whether the dependent file that the binary file depends on is a boundary rpm package. The boundary rpm package is used to represent the binary file whose dependent file is replaced in the target operating system. For details, please refer to Figure 1 Step S102 of the illustrated embodiment will not be described in detail here.

[0163] The recursive query module 1003 is used to recursively query the dependency relationship of the dependent files when the dependent files of the binary file are not boundary rpm packages, until the dependent files are boundary rpm packages. Figure 1 Step S103 of the illustrated embodiment will not be described in detail here.

[0164] The compatibility determination module 1004 is used to determine that the compatibility of the binary file is consistent with the compatibility of the dependent file when the dependent file that the binary file depends on is a boundary rpm package. Figure 1 Step S104 of the illustrated embodiment will not be described in detail here.

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

[0166] In some optional implementations, 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 and obtain the binary file 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, a second binary file screening unit is used to obtain an application software package of a source operating system and screen the binary file 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 the pre-built data base, where 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 and obtain the software packages reserved in the target operating system, and query the binary files contained in the reserved software packages.

[0172] In some optional embodiments, the data base is prepared by 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 the dynamic library file to be analyzed belongs in the target operating system, query and obtain the debugging file corresponding to the dynamic library file to be analyzed in the source operating system and the debugging file corresponding to the dynamic library file to be analyzed in the target operating system;

[0176] Based on the debugging file corresponding to the dynamic library file to be analyzed in the source operating system and the debugging file corresponding to the dynamic library file to be analyzed in the target operating system, ABI difference data of the dynamic library file to be analyzed is generated to obtain a data base.

[0177] In some optional implementations, the dependency query module 1002 includes:

[0178] The so library query unit is used to query the so library files that the binary file depends on.

[0179] The rpm package retention judgment unit is used to query the rpm package to which the so library file belongs in the target operating system based on the data base, and judge whether the rpm package is retained.

[0180] The boundary rpm package determination unit is used to determine that the dependent file that the binary file depends on is a boundary rpm package when the rpm package is not retained.

[0181] The non-boundary rpm package determination unit is used to determine the dependent file non-boundary rpm package that the binary file depends on when the rpm package is reserved.

[0182] In some optional implementations, the rpm package retention judgment unit includes:

[0183] The data base query subunit is used to query the data base to obtain the rpm package in the source operating system corresponding to the rpm package in the target operating system.

[0184] The rpm-so correspondence query subunit is used to query the rpm-so correspondence table in the data base based on the name of the rpm package in the target operating system, and determine whether there is a so library corresponding to the rpm package in the target operating system in the target operating system.

[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 the so library corresponding to the rpm package in the target operating system does not exist 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 that the so library depends on when there is a so library corresponding to the rpm package in the target operating system 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 that the so library depends on 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 that the so library depends on hits the ABI interface difference table.

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

[0191] The further functional description of each of the above modules and units is the same as that of the above corresponding embodiments and will not be repeated here.

[0192] The system migration compatibility analysis device in this embodiment is presented in the form of a functional unit, where the unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that executes 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 Fig.10 The system migration compatibility analysis device is shown.

[0194] See also Fig.11 , Fig.11 is a schematic diagram of the structure of a computer device provided by an optional embodiment of the present invention, such as Fig.11As shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in or on the memory to display the graphical information of the GUI on an external input / output device (such as, a display device coupled to the interface). In some optional 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 some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Fig.11 A processor 10 is taken as an example.

[0195] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic or any combination thereof.

[0196] 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 embodiment.

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

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

[0199] The computer device also 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 via a bus or other means. Fig.11 The example of connecting through bus is taken in the following.

[0200] The input device 30 can receive input digital or character information, and generate key signal input related to the user settings and function control of the computer device, such as a touch screen, a keypad, a mouse, a track pad, a touch pad, an indicator bar, 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 tactile feedback device (e.g., a vibration motor), etc. The above-mentioned display device includes but is not limited to a liquid crystal display, a light emitting diode, a display and a plasma display. In some optional embodiments, the display device can 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 can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium through a network download, 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 disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, etc.; further, the storage medium can 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 a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0202] A part of the present invention may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present invention through the operation of the computer. Those skilled in the art should understand that the existence of the computer program instruction in a computer-readable medium includes, but is not limited to, a source file, an executable file, an installation package file, etc., and accordingly, the way in which the computer program instruction is executed by the computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium may be any available computer-readable storage medium or communication medium accessible to the computer.

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

Claims

1. A system migration compatibility analysis method, characterized in that: The method comprises: Get the binary file of the software to be analyzed; Querying the dependency relationship of the binary file, and judging whether the dependent file on which the binary file depends is a boundary rpm package based on the dependency relationship, wherein the boundary rpm package is used to represent the binary file whose dependent file is replaced in the target operating system; When the dependent file that the binary file depends on 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, determining that the compatibility of the binary file is consistent with the compatibility of the dependent file; The ABI interface that the dependent file depends on is queried, and based on the ABI interface that the dependent file depends on, the compatibility of the software to be analyzed in the target operating system is determined.

2. The method according to claim 1, characterized in that The step of obtaining the binary file of the software to be analyzed includes: Obtaining an application software installation directory of the source operating system and an 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, filtering and obtaining the binary file of the software to be analyzed; and / or, obtaining an application software package of the source operating system, and screening to obtain a binary file of the software to be analyzed; Obtaining system software installed in the source operating system and a pre-built data base, wherein the pre-built data base is used to represent a difference data table between the source operating system and the target operating system; The data base is queried to filter and obtain software packages reserved in the target operating system, and binary files included in the reserved software packages are queried.

3. The method according to claim 2, characterized in that The data base is prepared by the following steps: Determine the dynamic library file to be analyzed; Obtaining 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; 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 debugging file corresponding to the dynamic library file to be analyzed in the source operating system and the debugging file corresponding to the dynamic library file to be analyzed in the target operating system; Based on the debugging file corresponding to the dynamic library file to be analyzed in the source operating system and the debugging file corresponding to the dynamic library file to be analyzed in the target operating system, ABI difference data of the dynamic library file to be analyzed is generated to obtain the data base.

4. The method according to claim 2, characterized in that: The querying of the dependency relationship of the binary file and judging whether the dependent file on which the binary file depends is a boundary rpm package based on the dependency relationship includes: Query the so library file that the binary file depends on; 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, determining that the dependent file on which the binary file depends is a boundary rpm package; When the rpm package is retained, a dependent file non-boundary rpm package on which the binary file depends is determined.

5. The method according to claim 4, characterized in that The querying, based on the data base, of the rpm package to which the so library file belongs in the target operating system comprises: Query the data base to obtain the rpm package in the target operating system corresponding to the rpm package in the source 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 a so library corresponding to the rpm package in the target operating system in the target operating system; When the target operating system does not have a so library corresponding to the rpm package in the target operating system, it is determined that the software to be analyzed is incompatible with the target operating system.

6. The method according to claim 5, characterized in that The querying of the ABI interface that the dependent file depends on, and determining the compatibility of the software to be analyzed in the target operating system based on the ABI interface that the dependent file depends on, includes: When there is a so library corresponding to the rpm package in the target operating system in the target operating system, read the ABI interface that the so library depends on; Querying the ABI interface difference table between the source operating system and the target operating system in the data base, and determining whether the ABI interface that the so library depends on hits the ABI interface difference table; When the ABI interface that the so library depends on hits the ABI interface difference table, determining that the software to be analyzed is incompatible with the target operating system; When the ABI interface that the so library depends on does not hit the ABI interface difference table, it is determined that the software to be analyzed is compatible with the target operating system.

7. A system migration compatibility analysis device, characterized in that: The device comprises: A file acquisition module, used to obtain the binary file of the software to be analyzed; A dependency query module, used to query the dependency of the binary file, and based on the dependency, determine whether the dependent file that the binary file depends on is a boundary rpm package, wherein 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, used for recursively querying the dependency relationship of the dependent file when the dependent file that the binary file depends on is not a boundary rpm package, until the dependent file is a boundary rpm package; A compatibility determination module, used for determining that the compatibility of the binary file is consistent with the compatibility of the dependent file when the dependent file on which the binary file depends is a boundary rpm package; The ABI analysis module is used to query the ABI interface that the dependent file depends on, and determine the compatibility of the software to be analyzed in the target operating system based on the ABI interface that the dependent file depends on.

8. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the system migration compatibility analysis method according to any one of claims 1 to 6 by executing the computer instructions.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the system migration compatibility analysis method according to any one of claims 1 to 6.

10. A computer program product, characterized in that The method comprises computer instructions, wherein 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 6.

Images