CN110716874B - Domestic operating system hardware compatibility testing method - Google Patents
Domestic operating system hardware compatibility testing method Download PDFInfo
- Publication number
- CN110716874B CN110716874B CN201910909108.5A CN201910909108A CN110716874B CN 110716874 B CN110716874 B CN 110716874B CN 201910909108 A CN201910909108 A CN 201910909108A CN 110716874 B CN110716874 B CN 110716874B
- Authority
- CN
- China
- Prior art keywords
- operating system
- kernel
- driver
- information
- knowledge base
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Prevention of errors by analysis, debugging or testing of software
- G06F11/3668—Testing of software
- G06F11/3672—Test management
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention relates to a domestic operating system hardware compatibility testing method, which is characterized by comprising the following steps: constructing an operating system kernel knowledge base; adding a driver dynamic dependency term into the knowledge base; statically scanning a driver file to obtain kernel information required by operation; performing dependency factor comparison, and if the major version numbers are inconsistent in comparison, judging that the operating system and the driver are incompatible; searching a driver name and a kernel version number in a knowledge base, statically scanning the obtained driver name and kernel version number, and judging the compatibility of an operating system; extracting source code layer information from the consistent items found in the knowledge base, respectively comparing the source code layer information with a header file source code, a derived function and a structure statement called by a driver obtained by static scanning, sequentially carrying out the order of the derived function or the structure statement information, and obtaining a comparison result; and giving operating system hardware compatibility and test reports.
Description
Technical Field
The invention relates to a domestic operating system compatibility test method, in particular to a domestic operating system hardware compatibility test method based on running element comparison.
Background
With the rapid development of operating systems based on home processors such as Loongson and Feiteng, various domestic operating system products such as kylin, general bloom and deep hundred flowers are put together, and a large amount of adaptation tests on hardware compatibility are performed in home-made key software and hardware directory tests.
However, because the products of various manufacturers lack unified product development specifications and standards at present, the situation that hardware equipment cannot be used compatibly due to the change of operating system versions often occurs, so that the compatibility test of hardware on an operating system is particularly important.
At present, operating system manufacturers do not have all hardware resources to be adapted, and lack of compatibility detection technical specifications and means and huge workload cause that direct development of compatibility tests by manufacturer access hardware becomes difficult. At present, research on compatibility test of an operating system at home and abroad is mainly focused on software, so that a general method for hardware compatibility test of a domestic operating system is not available. The domestic operating system hardware compatibility testing method based on the comparison of the elements of the operating environment aims at analyzing the dependency items required by the loading and the operation of the driving module in the operating system, carrying out query comparison on the driving module dependency items in the new version operating system according to the testing knowledge of the old version operating system, and giving out the hardware compatibility result of the new version operating system according to the comparison result. The method not only can solve the problem that the manufacturer of the operating system cannot develop the compatibility test or the testing workload is huge and difficult, but also can promote the user experience of the domestic operating system and promote the ecological health development of the domestic operating system.
Disclosure of Invention
The invention aims to provide a domestic operating system hardware compatibility testing method based on running environment element comparison, which solves the problem that the compatibility of hardware equipment cannot be used because all hardware equipment cannot be adapted after the current domestic operating system is updated.
The invention discloses a hardware compatibility testing method of a domestic operating system, which comprises the following steps: constructing an operating system kernel knowledge base; adding a driver dynamic dependency term into the knowledge base; statically scanning a driver file to obtain kernel information required by operation; performing a dependent element comparison, comprising: comparing the version number of the kernel where the driver is located when the driver is compiled for the first time with the version number of the kernel of the operating system to be tested, wherein the version number of the kernel is divided into three parts, namely a main version number, a secondary version number and a small version number, and if the main version number is inconsistent during comparison, the operating system and the driver are judged to be incompatible; secondly, searching a driver name, a kernel version number and a static scanning obtained driver name and kernel version number consistent items in a knowledge base, if not, backtracking to the latest item of the kernel version number with the consistent main version number, and if not, judging the compatibility of the operating system; after finding out the consistent item, comparing the interface call information of the consistent item with the interface call information obtained by static scanning, and if the interface call information is inconsistent with the interface call information, judging the compatibility of the operating system; thirdly, extracting information of a source code layer from the consistent items found in the knowledge base, respectively comparing the information with a header file source code, a derived function and a structure statement called by a driver program obtained through static scanning, sequentially carrying out comparison according to the sequence of the header file source code, the derived function or the structure statement information by taking the function or the structure as a unit, and obtaining a comparison result; and giving operating system hardware compatibility and test reports.
According to the domestic operating system hardware compatibility testing method, the construction of the operating system kernel knowledge base comprises the following steps: linking the export function and the structure of the kernel of the operating system, wherein the declarations of the export function and the structure are concentrated in a header file provided by a kernel development kit; the kernel knowledge base of the operating system stores the dependency element information of the known operating system, and firstly, the obtained kernel version of the operating system and the header file source codes in the kernel development kit are stored in the knowledge base; then, for each header file, signature information of its internal function declaration and structure definition is extracted.
According to one embodiment of the domestic operating system hardware compatibility testing method, when known peripheral hardware exists, a driver kernel calling information acquisition module is firstly created, the running process of a hardware device driver is monitored, the interface calling of the hardware device driver in the kernel is recorded, and for the driver which completes monitoring, device information is added into a knowledge base, and the driver module and a knowledge item of interface calling information.
According to an embodiment of the method for testing hardware compatibility of a domestic operating system, the flow description of static scanning comprises the following steps: determining the version number of the kernel where the driver is located when the driver is compiled for the first time; determining an export function called by a driver; searching all header files in the kernel development kit; and searching the exported functions called by the driver in the header file according to the sequence, and determining the declaration information of the structural body in the header file where the exported functions are located.
According to an embodiment of the hardware compatibility testing method of the domestic operating system, the dependency elements to be compared are divided into a kernel version number, interface call information of a driver, a header file code implementation, an export function in a header file and structure declaration information.
According to an embodiment of the hardware compatibility testing method of the domestic operating system, in the fifth step, according to the comparison result, the compatibility of the operating system is divided into the following several levels: compatibility: if the kernel version number of the driver is consistent with the kernel version number of the operating system to be tested in initial compiling, and knowledge items consistent with the driver and the kernel version are found in the kernel knowledge base of the operating system, which indicates that the kernel implementation of the system to be tested is consistent with the kernel implementation of the original adaptation system of the driver, the driver is judged to be compatible with the current system to be tested; not compatible with: when the major version numbers of the kernel of the operating system are inconsistent or the comparison of code layers is carried out, header files exist, and the comparison of export functions or structural body declarations is inconsistent; the method is basically compatible: if the kernel major version numbers are consistent and only have the difference of minor version numbers, judging that the driver is basically compatible with the system to be tested and has tiny running risk according to the comparison result of interface call information obtained by the knowledge base and the static scanning, and judging that all derived functions and structural body changes do not influence the compatibility of the operating system through the comparison of code layers if the comparison result is consistent; the method cannot judge: if the major version numbers are consistent and only have the difference of the minor version numbers, and the comparison result of the interface call information obtained by static scanning of the knowledge base is inconsistent, or no item consistent with the primary version number of the kernel and the primary version number of the kernel of the original adaptation of the driver is found when searching the knowledge base, whether the driver is compatible with the system to be tested can not be judged.
According to an embodiment of the domestic operating system hardware compatibility testing method, the compatibility testing report should include version information of the operating system to be tested, a driver name, testing time, operating system compatibility and function comparison results.
According to an embodiment of the method for testing hardware compatibility of a domestic operating system, in the third step, the comparison result includes: if the comparison results of the header file documents are consistent, all export functions and structure statement in the header file are not changed, the calling of the interface is not affected, and the export functions and the structure under the header file are not compared; the comparison result of the header file documents is inconsistent, and the declaration information of the export function or the structure body is consistent, so that the declaration of the export function or the structure body is not changed and the calling of the interface is not affected; the header file document is inconsistent in comparison, and the function or structure declaration information is exported, so that the function or structure change is considered to influence the calling of the driver to the interface, and the operating system cannot be compatible upwards.
According to one embodiment of the domestic operating system hardware compatibility testing method, an operating system kernel knowledge base collects kernel version information of an operating system, collects kernel development package resources, distinguishes header files, and exports function and structure declarations.
According to the embodiment of the domestic operating system hardware compatibility testing method, the operating system kernel knowledge base extracts and stores signature information of the derived functions and the structural bodies based on analysis of factors affecting the operating system hardware compatibility during kernel source code modification.
The invention provides a domestic operating system hardware compatibility test method based on running environment element comparison, which constructs a knowledge base of information such as domestic operating system kernel version, derived functions, structure body signature and the like; the method comprises the steps that dynamic tracking and monitoring are carried out on the operation process of a driving module of the hardware equipment in the operation process of the hardware equipment, so that operation dependent elements of the driving module for an operating system kernel are obtained and stored in a knowledge base to form equipment information, and the driving module depends on knowledge items formed by the elements; and when the subsequent operating system is released, the driving module information and the current kernel information provided by the scanning operating system are subjected to static analysis, the knowledge in the knowledge base is traced back and the comparison of the dependent elements is carried out, and finally, the hardware compatibility test result of the domestic operating system is given out through the comparison result. The method can provide means for compatibility test of the domestic operating system, realize hardware compatibility test of the domestic operating system without hardware equipment after upgrading, give out compatibility test results, and propose modification suggestions for operating system manufacturers and hardware driver developers; the construction of hardware development standards of domestic operating systems is promoted.
Drawings
FIG. 1 is a schematic diagram illustrating the operation of a driver kernel;
FIG. 2 is a diagram illustrating a comparison of kernel information with information related to the kernel knowledge base of an operating system;
fig. 3 is a flow chart showing the comparison of the dependent elements.
Detailed Description
For the purposes of clarity, content, and advantages of the present invention, a detailed description of the embodiments of the present invention will be described in detail below with reference to the drawings and examples.
The invention discloses a hardware compatibility testing method of a domestic operating system, which comprises the following steps:
the first step of constructing an operating system kernel knowledge base comprises the following steps:
the driver program runs in the operating system and needs to dynamically link interfaces (including export functions and structs) provided by the kernel of the operating system, and kernel information (version number of kernel) of the operating system where the module is compiled for the first time is stored in the driver module. The kernel knowledge base of the operating system mainly collects kernel version information of the operating system, and simultaneously collects kernel development package resources, distinguishes header files and exporting functions and structure statement. The kernel knowledge base of the operating system extracts and stores signature information of derived functions and structures based on analysis of factors which possibly affect the compatibility of hardware of the operating system when kernel source codes are modified.
The second step adds a driver dynamic dependency term to the knowledge base, comprising:
to test the hardware compatibility of the target operating system, the environment of the adapted hardware, the driver and the kernel is required to be taken as a benchmark, so that the running condition of the known peripheral hardware in the kernel of the known operating system is required to be collected and added into the kernel knowledge base of the operating system as knowledge. In the presence of known peripheral hardware, a driver is created that can monitor other driver modules in the operating system kernel, and loaded into the kernel. Selecting a driving module to be tested, monitoring the interface call of the driving module when the peripheral hardware is used, and writing the module name, the kernel version and the called interface into a kernel knowledge base of a system.
The third step of static scanning the driver file, comprising:
when the hardware compatibility test is carried out, peripheral hardware is often lacking, and the compatibility test can not be carried out on the hardware in a dynamic test mode. At this time, static scanning is required for the selected driver module based on the ELF file format, and the kernel version of the operating system where the driver module is initially compiled, and the derived functions and structure information called by the driver module are scanned.
The fourth step of dependent element comparison comprises:
after static scanning obtains kernel calling information of a driver, knowledge items composed of equipment information, a driving module and operation elements are traced in an operating system kernel knowledge base, the dependent operation elements are compared, and a comparison result is given.
And fifthly, providing an operating system hardware compatibility and a test report, wherein the method comprises the following steps:
and according to the comparison result, a hardware compatibility test report of the operating system is provided, wherein the report comprises target operating system version information, a driver name, test time, a hardware and operating system compatibility result and a detailed compatibility detection description. Different colors are used for factors that cause the hardware to be incompatible with the operating system.
Another embodiment of the method for testing hardware compatibility of a domestic operating system based on comparison of elements of an operating environment of the invention comprises the following steps:
the first step of constructing an operating system kernel knowledge base comprises the following steps:
the driver runs in the operating system with the need to link the export functions and constructs of the operating system kernel, whose declarations are concentrated in the header file provided by the kernel development kit.
When an operating system is updated, the kernel implementation of the operating system is often modified to a certain extent. In order to ensure that the driver module can be used in a new operating system without modification, the modification of the kernel cannot in principle change the declaration of the function and the structure, and is embodied in the number and type of parameters of the function, the return value type of the function, and the number and type of members in the structure. Each header file holds an unequal number of export functions and declarations of constructs. When the system is updated, the whole head file is not changed, and functions and structure statement in the head file are not changed, so that comparison one by one is not needed. Based on the above analysis, the dependency element first includes the version number of the kernel, header information, export functions, and declaration information of the structure.
The operating system kernel knowledge base stores dependency element information of known operating systems. Firstly, storing the obtained kernel version of the operating system and header file source codes in a kernel development kit in a knowledge base; then, for each header file, the signature information of its internal function declarations (symbol name, parameter type, number, return value type) and structure definition is extracted.
The second step adds a driver dynamic dependency term to the knowledge base, comprising:
in order to ensure the accuracy of the test, the proper hardware, driver and kernel environment is required to be used as a benchmark, and compatibility test is performed on the basis of ensuring that the driver module can run in the kernel of the known operating system.
Fig. 1 is a schematic diagram of the operation of a driver kernel, and when there is a known peripheral hardware, as shown in fig. 1, a driver kernel call information acquisition module is first created, and this module operates in kernel space, monitors the operation process of a hardware device driver, and records the interface call in the kernel.
And for the driver program for completing monitoring, adding equipment information into the knowledge base, driving the module, and calling knowledge items of the information by the interface.
In order to ensure the completeness of the collected data, the kernel knowledge base of the operating system is stored in a common server, and any user using the knowledge base can add data into the server after collecting knowledge base information, so that the continuous expansion and perfection of the knowledge base are ensured.
The third step of static scanning the driver file, comprising:
fig. 2 is a schematic diagram illustrating comparison between kernel information and related information in a kernel knowledge base of an operating system, as shown in fig. 2, when a compatibility test is performed, in most cases, peripheral hardware to be tested is absent, and the compatibility test cannot be performed on the hardware by using a dynamic test method. At this time, the driver to be tested needs to be scanned based on the ELF file format to obtain the kernel information required by the running of the driver, and the kernel information is compared with the related information in the kernel knowledge base of the operating system.
The flow of static scanning is described as follows:
first, the version number of the kernel where the driver is located at the time of initial compiling is determined.
And secondly, determining an export function called by the driver.
And thirdly, searching all header files in the kernel development kit.
And fourthly, searching the derived functions called by the driver in the header file according to the sequence and determining the declaration information of the structural body in the header file where the derived functions are located.
The fourth step of dependent element comparison comprises:
through summarization, the dependency elements to be compared are divided into kernel version number, interface call information of a driver, header code implementation, export function in a header and structure declaration information.
Through the design of the three steps, all the dependence elements to be compared are found and stored. The dependency elements are then compared and the comparison result is given.
Fig. 3 is a flowchart of comparison of dependent elements, and as shown in fig. 3, the following is a specific description:
firstly, comparing the version number of the kernel where the driver is located when the driver is compiled for the first time with the version number of the kernel of the operating system to be tested. The version number of the kernel is divided into three parts, namely a major version number, a minor version number and a minor version number. If the major version numbers are inconsistent in comparison, the operating system and the driver are judged to be incompatible, and the subsequent comparison is not performed; otherwise, continuing to perform downward comparison to determine whether the two are compatible.
And secondly, searching the names of the drivers and the kernel version numbers in the knowledge base, and if the names of the drivers and the kernel version numbers which are obtained through static scanning are not found, backtracking the latest item of the kernel version numbers with the consistent main version numbers. If no item with the same main version number is found, the compatibility of the operating system cannot be judged, and the subsequent comparison is not performed; after the item is found, the interface call information of the item is compared with the interface call information obtained by static scanning, if the interface call information is inconsistent with the interface call information, the compatibility of the operating system cannot be judged, the subsequent comparison is not performed, and if the interface call information is consistent with the interface call information, the kernel source codes of the operating system are continuously compared.
And thirdly, extracting information of a source code layer from the items found in the knowledge base in the last step, and comparing the information with a header file source code, a derived function and a structural body statement called by a driver obtained through static scanning. The comparison is carried out sequentially by taking the function or the structure body as a unit according to the source codes of the header files and the order of deriving the declaration information of the function or the structure body. The results of the comparison are divided into the following cases:
and the comparison results of the header files are consistent, and all the export functions and the structure statement in the header files are considered to be unchanged, so that the calling of the interface is not influenced, and the export functions and the structure under the header files are not compared.
The comparison result of the header file documents is inconsistent, the declaration information of the export function or the structure body is consistent, and the declaration of the export function or the structure body is considered to be unchanged, so that the calling of the interface is not influenced.
The header file document is inconsistent in comparison, and the function or structure declaration information is exported, so that the function or structure change is considered to influence the calling of the driver to the interface, and the operating system cannot be compatible upwards.
Fifth step, providing operating system hardware compatibility and test report
After the dependency item comparison is executed, a compatibility test result and a test report of the operating system are required to be given according to the comparison result. According to the comparison result, the compatibility of the operating system is divided into the following levels:
compatibility: if the kernel version number of the driver is consistent with the kernel version number of the operating system to be tested when the driver is initially compiled, and knowledge items consistent with the driver and the kernel version are found in the kernel knowledge base of the operating system, which indicates that the kernel implementation of the system to be tested is consistent with the kernel implementation of the original adaptation system of the driver, the driver can be judged to be compatible with the current system to be tested;
not compatible with: when the major version numbers of the operating system kernels are inconsistent or the comparison of the code layers is carried out, the head files exist, and the comparison of the derived functions or the structural body declarations is inconsistent.
The method is basically compatible: if the kernel major version numbers are consistent and only have the difference of minor version numbers, according to the comparison result of interface call information obtained by the knowledge base and static scanning, if the comparison result is consistent, and the comparison of the code layers is carried out, the compatibility of the operating system is not affected by all derived functions and structural body changes. It is determined that the driver is substantially compatible with the system under test, and there may be a minor running risk, but this is relatively easy to resolve.
The method cannot judge: if the major version numbers are consistent and only have the difference of the minor version numbers, and the comparison result of the interface call information obtained by static scanning of the knowledge base is inconsistent, or no item consistent with the primary version number of the kernel and the primary version number of the kernel of the original adaptation of the driver is found when searching the knowledge base, whether the driver is compatible with the system to be tested can not be judged.
The compatibility test report should include version information of the operating system to be tested, the name of the driver, the test time, operating system compatibility, and function comparison results. For reasons that render the operating system incompatible upwards, red color should be used for labeling in order to facilitate modifications for each manufacturer.
The domestic operating system hardware compatibility testing method based on the comparison of the elements of the operating environment has the following characteristics:
the compatibility testing method is suitable for the current domestic operating system;
the method is characterized in that a distributed fusible knowledge base is formed, a large number of versions of kernel information of different domestic operating systems are integrated, the hardware driving module operates to rely on element knowledge, a plurality of operating system manufacturers are converged, and the test knowledge of a third-party testing mechanism promotes the development of the domestic operating systems;
the compatibility test result is given, the factors causing incompatibility of the operating system and the hardware are displayed, and convenience is provided for the operating system manufacturer and the hardware developer to modify.
Supporting multi-format output of test results, and providing a data format description means for each output, thereby providing a basic support for developing a generalized test tool or platform;
aiming at the problem that the existing domestic operating system lacks a hardware compatibility test method, the invention adopts the following method and steps to realize the hardware compatibility test of the domestic operating system: firstly, constructing a kernel version of a domestic operating system, and deriving a knowledge base of information such as functions, structure body signatures and the like; secondly, designing a drive tracking module, tracking interface call when a drive program runs in the running process of hardware equipment, acquiring a drive program running dependent element, adding equipment information into a knowledge base, and enabling the drive module and the interface to call knowledge items formed by the information; step three, statically scanning a driver file on the operating system of the version to be tested to obtain a dependent element item required by the running of the driver; step four, tracing the knowledge items of the dependent operation elements in the knowledge base according to the driving module, obtaining the dependent elements under the original operating system and comparing the dependent elements with the information of the dependent elements of the current operating system obtained by scanning; fifthly, according to the comparison result, an operating system hardware compatibility test result is given.
The foregoing is merely a preferred embodiment of the present invention, and it should be noted that modifications and variations could be made by those skilled in the art without departing from the technical principles of the present invention, and such modifications and variations should also be regarded as being within the scope of the invention.
Claims (9)
1. A domestic operating system hardware compatibility testing method is characterized by comprising the following steps:
constructing an operating system kernel knowledge base;
adding a driver dynamic dependency term into the knowledge base;
statically scanning a driver file to obtain kernel information required by operation;
performing a dependent element comparison, comprising:
comparing the version number of the kernel where the driver is located when the driver is compiled for the first time with the version number of the kernel of the operating system to be tested, wherein the version number of the kernel is divided into three parts, namely a main version number, a secondary version number and a small version number, and if the main version number is inconsistent during comparison, the operating system and the driver are judged to be incompatible;
secondly, searching a driver name, a kernel version number and a static scanning obtained driver name and kernel version number consistent items in a knowledge base, if not, backtracking to the latest item of the kernel version number with the consistent main version number, and if not, judging the compatibility of the operating system; after finding out the consistent item, comparing the interface call information of the consistent item with the interface call information obtained by static scanning, and if the interface call information is inconsistent with the interface call information, judging the compatibility of the operating system;
thirdly, extracting information of a source code layer from the consistent items found in the knowledge base, respectively comparing the information with a header file source code, a derived function and a structure statement called by a driver program obtained through static scanning, sequentially carrying out comparison according to the sequence of the header file source code, the derived function or the structure statement information by taking the function or the structure as a unit, and obtaining a comparison result;
giving a test result and a test report of the compatibility of the hardware of the operating system;
the hardware compatibility of the operating system is divided into the following levels:
compatibility: if the kernel version number of the driver is consistent with the kernel version number of the operating system to be tested in initial compiling, and knowledge items consistent with the driver and the kernel version are found in the kernel knowledge base of the operating system, which indicates that the kernel implementation of the system to be tested is consistent with the kernel implementation of the original adaptation system of the driver, the driver is judged to be compatible with the current system to be tested;
not compatible with: when the major version numbers of the kernel of the operating system are inconsistent or the comparison of code layers is carried out, header files exist, and the comparison of export functions or structural body declarations is inconsistent;
the method is basically compatible: if the kernel major version numbers are consistent and only have the difference of minor version numbers, judging that the driver is basically compatible with the system to be tested and has tiny running risk according to the comparison result of interface call information obtained by the knowledge base and the static scanning, and judging that all derived functions and structural body changes do not influence the compatibility of the operating system through the comparison of code layers if the comparison result is consistent;
the method cannot judge: if the major version numbers are consistent and only have the difference of the minor version numbers, and the comparison result of the interface call information obtained by static scanning of the knowledge base is inconsistent, or no item consistent with the primary version number of the kernel and the primary version number of the kernel of the original adaptation of the driver is found when searching the knowledge base, whether the driver is compatible with the system to be tested can not be judged.
2. The method for testing hardware compatibility of a domestic operating system according to claim 1, wherein constructing an operating system kernel knowledge base comprises:
linking the export function and the structure of the kernel of the operating system, wherein the declarations of the export function and the structure are concentrated in a header file provided by a kernel development kit;
the kernel knowledge base of the operating system stores the dependency element information of the known operating system, and firstly, the obtained kernel version of the operating system and the header file source codes in the kernel development kit are stored in the knowledge base; then, for each header file, signature information of its internal function declaration and structure definition is extracted.
3. The method for testing hardware compatibility of domestic operating system according to claim 1, wherein when there is a known peripheral hardware, firstly creating a driver kernel call information acquisition module, monitoring the running process of the hardware device driver, recording interface call in the kernel, adding device information to the knowledge base for the driver that completes monitoring, driving the module, and calling knowledge items of the information by the interface.
4. The method for testing hardware compatibility of a domestic operating system according to claim 1, wherein the flow description of the static scan comprises:
determining the version number of the kernel where the driver is located when the driver is compiled for the first time;
determining an export function called by a driver;
searching all header files in the kernel development kit;
and searching the exported functions called by the driver in the header file according to the sequence, and determining the declaration information of the structural body in the header file where the exported functions are located.
5. The method of claim 1, wherein the dependency elements to be compared are divided into kernel version number, interface call information of driver, header code implementation, export function in header, and structure declaration information.
6. The method of claim 1, wherein the compatibility test report includes version information of the operating system to be tested, a driver name, a test time, operating system compatibility, and a function comparison result.
7. The method for testing hardware compatibility of a domestic operating system according to claim 1, wherein the comparing result comprises:
if the comparison results of the header file documents are consistent, all export functions and structure statement in the header file are not changed, the calling of the interface is not affected, and the export functions and the structure under the header file are not compared;
the comparison result of the header file documents is inconsistent, and the declaration information of the export function or the structure body is consistent, so that the declaration of the export function or the structure body is not changed and the calling of the interface is not affected;
the header file document is inconsistent in comparison, and the function or structure declaration information is exported, so that the function or structure change is considered to influence the calling of the driver to the interface, and the operating system cannot be compatible upwards.
8. The method of claim 1, wherein the operating system kernel knowledge base gathers kernel version information of the operating system, gathers kernel development package resources, distinguishes header files and exports function and structure declarations.
9. The method for testing hardware compatibility of a domestic operating system according to claim 1, wherein the operating system kernel knowledge base extracts and stores signature information of derived functions and structures based on analysis of factors affecting the hardware compatibility of the operating system when kernel source codes are modified.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910909108.5A CN110716874B (en) | 2019-09-25 | 2019-09-25 | Domestic operating system hardware compatibility testing method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910909108.5A CN110716874B (en) | 2019-09-25 | 2019-09-25 | Domestic operating system hardware compatibility testing method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110716874A CN110716874A (en) | 2020-01-21 |
| CN110716874B true CN110716874B (en) | 2023-08-22 |
Family
ID=69210811
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910909108.5A Active CN110716874B (en) | 2019-09-25 | 2019-09-25 | Domestic operating system hardware compatibility testing method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110716874B (en) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20220147636A1 (en) * | 2020-11-12 | 2022-05-12 | Crowdstrike, Inc. | Zero-touch security sensor updates |
| CN112328494B (en) * | 2020-11-26 | 2022-02-18 | 浪潮电子信息产业股份有限公司 | A compatibility detection method, apparatus, device and readable storage medium |
| CN113934642B (en) * | 2021-11-19 | 2024-05-14 | 四川启睿克科技有限公司 | Software compatibility testing method based on dynamic and static combination |
| CN114676069B (en) * | 2022-05-30 | 2022-08-30 | 深圳市科力锐科技有限公司 | Kernel file testing method, device, equipment and storage medium |
| CN116795452B (en) * | 2023-07-20 | 2024-04-02 | 龙芯中科(北京)信息技术有限公司 | Method, device and equipment for determining compatibility of driving program |
| CN118193071B (en) * | 2024-03-29 | 2025-01-17 | 浪潮电子信息产业股份有限公司 | A hardware chip access method, device, equipment and medium |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108205503A (en) * | 2016-12-16 | 2018-06-26 | 龙芯中科技术有限公司 | Hardware driving compatibility method and terminal |
| CN109033816A (en) * | 2018-06-15 | 2018-12-18 | 中国人民解放军国防科技大学 | Domestic office peripheral drive management method and system on kylin operating system platform |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7571445B2 (en) * | 2001-11-29 | 2009-08-04 | Dell Products L.P. | System and method for dynamic device driver support in an open source operating system |
| US9483284B2 (en) * | 2011-02-25 | 2016-11-01 | Red Hat, Inc. | Version compatibility determination |
| US9015702B2 (en) * | 2012-01-13 | 2015-04-21 | Vasanth Bhat | Determining compatibility of an application with different versions of an operating system |
-
2019
- 2019-09-25 CN CN201910909108.5A patent/CN110716874B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108205503A (en) * | 2016-12-16 | 2018-06-26 | 龙芯中科技术有限公司 | Hardware driving compatibility method and terminal |
| CN109033816A (en) * | 2018-06-15 | 2018-12-18 | 中国人民解放军国防科技大学 | Domestic office peripheral drive management method and system on kylin operating system platform |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110716874A (en) | 2020-01-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110716874B (en) | Domestic operating system hardware compatibility testing method | |
| US10162738B2 (en) | System, method, and computer readable medium for universal software testing | |
| US7299451B2 (en) | Remotely driven system for multi-product and multi-platform testing | |
| US5956513A (en) | System and method for automated software build control | |
| US9582394B2 (en) | Encapsulating and managing diagnostic information | |
| US20050262482A1 (en) | System and method for efficiently analyzing and building interdependent resources in a software project | |
| US7536678B2 (en) | System and method for determining the possibility of adverse effect arising from a code change in a computer program | |
| CN110716873B (en) | Method for constructing hardware compatibility knowledge base | |
| CN112181858B (en) | Automatic detection method for Java software project dependent conflict semantic consistency | |
| US11422917B2 (en) | Deriving software application dependency trees for white-box testing | |
| US20070050427A1 (en) | System and method for validating application globalization issues and computer product | |
| CN101901148A (en) | Method for generating ECU parameter configuration interface based on AUTOSAR standard | |
| JP5976209B2 (en) | Program analysis apparatus, program analysis method, and program analysis program | |
| WO2017164856A1 (en) | Comparable user interface object identifications | |
| US20080022263A1 (en) | Identifying The Origin Of Application Resources | |
| US7895575B2 (en) | Apparatus and method for generating test driver | |
| JP4795446B2 (en) | Operation verification apparatus and operation verification program | |
| CN116431486A (en) | Method, system, terminal equipment and storage medium for abnormality test applied to UI automation | |
| CN113688031B (en) | Test positioning method based on byte code enhancement technology | |
| CN115344282A (en) | Method, device, equipment and medium for determining test interface and generating function call chain | |
| US20090007068A1 (en) | Accessing Non-Public Code | |
| CN114218104A (en) | Mobile terminal testing method and device based on AT instruction and storage medium | |
| JP2002014847A (en) | Device for checking program and method for the same and recording medium with checking program stored | |
| CN117076288A (en) | Dynamic debugging method and device for applications in ios | |
| CN118535221A (en) | Application software compatibility evaluation method applied to operating system migration |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |