Automatic analysis method of Linux kernel source code

Abstract

The invention provides an automatic analysis method of a Linux kernel source code. The method comprises the following steps: setting a rule definition of each statement block, and decomposing a Linux kernel source code into an annotation statement block, a function statement block (subdivided into a function declaration statement block and a function definition statement block), a global variable statement block, a user-defined data type statement block and a macro definition statement block according to the rule definition; each statement block serves as a module, and an inter-module relation table and a data and inter-module relation table are analyzed; according to the method, through a full-automatic analysis process, the whole Linux kernel source code can be systematically analyzed under the condition that manual intervention is not needed, and a structured analysis result is output.

Description

Technical Field

[0001] The present invention relates to the technical field of computer applications, and in particular to an automatic analysis method for Linux kernel source code. Background Art

[0002] With the development of open source software, the Linux kernel, as an important open source project, has attracted the participation of many developers around the world. The Linux kernel source code is complex, involving multiple programming techniques and a large number of lines of code. Its structure and function deeply affect the operation of modern computer systems. However, understanding and maintaining these source codes is a difficult task for developers, especially when faced with a large and complex code base, and traditional manual analysis methods are particularly inefficient. Existing source code analysis tools usually rely on manual review and simple static analysis, and cannot deeply analyze the structural relationships in the code. These tools often cannot fully identify and extract key modules in the source code, which makes developers spend time and effort in analyzing the code. In this context, developers urgently need a tool that can automatically process and analyze the Linux kernel source code to improve analysis efficiency and accuracy.

[0003] At present, one source code analysis method in the prior art includes: professional technicians need to use tools such as code analyzers to perform manual analysis. These tools can perform basic static analysis, but they are often limited to simple syntax and logic checks and cannot deeply understand the complex structure of the source code.

[0004] The disadvantages of the source code analysis methods in the above-mentioned prior art include: the existing static analysis tools can usually only perform superficial syntax checking and error detection, and cannot deeply understand the logical structure of the code. For example, they cannot analyze complex module dependencies, relationships between data, etc. This makes it difficult for developers to fully grasp the operating mechanism of the program and the interaction between modules when analyzing the code. Moreover, the existing tools usually rely on the manual operation and analysis of the developer, and cannot achieve fully automatic source code analysis.

[0005] Developers need to manually trigger scans and view results. These tools cannot automatically extract and classify different types of code elements, which is inefficient. Many static analysis tools have limited scalability and cannot be customized for specific needs. These tools often seem unable to meet the specific needs of large-scale and complex projects. Summary of the invention

[0006] The embodiment of the present invention provides an automatic analysis method for Linux kernel source code, so as to effectively improve the analysis efficiency and accuracy of Linux kernel source code.

[0007] In order to achieve the above object, the present invention adopts the following technical scheme.

[0008] The automatic analysis method of Linux kernel source code includes:

[0009] Set a rule definition for each statement block, and decompose the Linux kernel source code into a comment statement block, a function statement block, a global variable statement block, a user-defined data type statement block, and a macro definition statement block according to the rule definition, wherein the function statement block includes a function declaration statement block and a function definition statement block;

[0010] Take each statement block as a module and analyze the relationship table between modules and the relationship table between data and modules.

[0011] Preferably, the rule definition for setting each statement block includes: each statement block includes a comment statement block, a function statement block, a global variable statement block, a user-defined data type statement block and a macro definition statement block, and the function statement block includes a function declaration statement block and a function definition statement block;

[0012] The rule for comment blocks is defined as follows: if two consecutive forward slashes ( / / ) appear in the area outside the quotation marks, the line to the end of the line is a single-line comment block; if a forward slash and an asterisk ( / *) appear consecutively in the area outside the quotation marks, and there must be a closed end symbol, that is, consecutive asterisks and forward slashes (* / ), it is a multi-line comment block;

[0013] The rule of function statement block is defined as follows: a statement block that meets the above conditions in the global scope ends with a semicolon (;), and there is a pair of parentheses before the semicolon. The content in the pair of parentheses is the parameter type plus the parameter variable list and can be empty, which is a function declaration statement block; a statement block that meets the above conditions in the global scope ends with a right curly brace (}), and the content in the pair of curly braces is the function body. There is a pair of parentheses before the pair of curly braces. The content in the pair of parentheses is the parameter type plus the parameter variable list and can be empty, which is a function definition statement block;

[0014] The rule for global variable statement blocks is defined as follows: a statement block in the global domain that meets the conditions, ends with a semicolon, and is preceded by a variable name or a value assigned to the variable, is a global variable statement block;

[0015] The rule for a custom data type statement block is defined as follows: a statement block in the global scope that meets the above conditions, ends with a semicolon, is preceded by a structure variable name or a pair of curly braces, and contains the keywords struct, enum, union, and typedef is a custom data type statement block;

[0016] The rule of macro definition block is defined as follows: a block of statements in the global domain that meets the conditions, whose first character is a pound sign (#), and whose next non-empty string in the line is the word define, is a macro definition block.

[0017] Preferably, the decomposing the Linux kernel source code into comment statement blocks, function statement blocks, global variable statement blocks, user-defined data type statement blocks and macro definition statement blocks according to the rule definition includes:

[0018] Step S1, perform a preliminary scan on all source files in the Linux kernel source code, and proceed to step S2;

[0019] Step S2: symbol level preprocessing:

[0020] 1) Create a symbol stack, which includes a nested level of tracking bracket and quotation mark symbols;

[0021] 2) Scanning and symbol matching criteria:

[0022] a) Bracket matching: Scan each line in the file and maintain a symbol stack to match parentheses (), square brackets [], and curly brackets {}. Whenever a left bracket is encountered, the position of the left bracket is pushed onto the stack; when a right bracket is encountered, the right bracket is popped from the stack to ensure a match;

[0023] b) Quote matching: Scan and match double quotes "" and single quotes "", and whenever a left quote is encountered, push the position of the left quote into the stack to ensure the integrity of the string literal;

[0024] c) Quote matching takes precedence over bracket matching: if a left quote is encountered first, it is processed as a quote match, that is, the brackets between the left and right quotes are treated as ordinary characters;

[0025] d) Quote nesting matching: Matches the first left quote type encountered, that is, any quotes between the first left quote and its corresponding right quote will be treated as ordinary characters;

[0026] e) Nested symbol matching in comment blocks: Any symbol appearing in a comment block, including brackets and quotation marks, will be treated as ordinary characters;

[0027] Go to step S3.

[0028] Step S3, scanning each line in the source file line by line to identify a specific programming construct;

[0029] 1) Annotation recognition:

[0030] When / / appears in a line, read to the end of the line, identify it as a comment block, and jump to step S4.

[0031] When / * appears in a line, continue reading to the next * / , which is a comment, and then jump to step S4;

[0032] 2) Macro definition identification:

[0033] When the first character of a line is # and it is followed by define after skipping the blank character, it is recorded as a macro definition statement block. If the line ends with \, the next line is read continuously until a non-\ character is encountered. The macro definition statement block is completely recorded and the process jumps to step S4.

[0034] 3) Custom data type identification:

[0035] When the typedef, struct, union or enum keyword is detected, the content is read until a semicolon is encountered. This section of content is recorded as a custom data type statement block and jumps to step S4.

[0036] 4) Variable and function identification:

[0037] Detect possible variable types or return value types and enter the variable and function judgment process:

[0038] a) If the text does not contain matching brackets (), the text is recorded as a global variable statement block;

[0039] b) If the text contains paired brackets (), it is considered a function statement block. If the ending character is a semicolon, it is recorded as a function declaration.

[0040] c) If the end character is a left brace {, which is the beginning of the function body, then symbol matching starts from the current left brace { until the end brace} is encountered, and this section of text is recorded as a function statement block;

[0041] Jump to step S4;

[0042] Step S4, return to scanning: After completing the above steps, return to step S3 and continue scanning the source file until all the contents of the source file are read.

[0043] Preferably, the method of treating each statement block as a module and analyzing the inter-module relationship table and the data-module relationship table includes:

[0044] Step S1, traverse the function prototype list:

[0045] The system traverses the identified function prototype list to determine the definition location of each function. After completing the location, it proceeds to step S2;

[0046] Step S2, traverse the header file of the source code:

[0047] The system analyzes the header file calling relationship in the source code file, retrieves the referenced header file, and continues to retrieve the variable table and function prototype table to obtain the declaration position of the variable and function, and then enters step S3;

[0048] Step S3, traverse function definition:

[0049] The system parses the function definition and performs two types of traversal work

[0050] 1) Traverse function calls:

[0051] The system analyzes the definition of each function, traverses the called functions, and calls the function prototype table and header file

[0052] Relationship, determine the location of the called function, and record the calling relationship between functions in the inter-module relationship table;

[0053] 2) Traverse variable calls:

[0054] The system traverses the variables used in the function definition, locks the called global variables through the global variable table and header file calling relationship, excludes local variables, and records the data interaction relationship between modules in the data and module relationship table;

[0055] Step S4, return to the function prototype list and continue scanning:

[0056] After completing the traversal of the current function definition, the system returns to the function prototype list, continues to scan the next function, and repeats steps S2 and S3 until all function prototypes are traversed to generate the module relationship table and the data and module relationship table.

[0057] Preferably, the method further comprises:

[0058] Step S1, traverse the global variable list:

[0059] Starting from the list of global variables identified in the traversal system, the definition and usage of each global variable are checked in turn, and their interaction relationship with other modules is analyzed, and then step S2 is entered;

[0060] Step S2, traverse the global variables in the source code file:

[0061] Traverse the source code files, find the definition and usage location of the global variables in each file, determine the specific location of each global variable in the code, and enter step S3;

[0062] Step S3: Check whether the global variable has dependencies with other variables:

[0063] After finding the global variable, determine whether the global variable has a dependency relationship with other global variables. This dependency relationship may be manifested in mutual calling, assignment or modification between global variables. If a dependency relationship is found, go to step S4; if not, jump directly to step S2 and continue to traverse the next global variable;

[0064] Step S4: record the dependency relationship between the global variable and other global variables:

[0065] If the system finds that there is a dependency relationship between global variables, it will record it in the data relationship table and go to step S5;

[0066] Step S5: The global variable list is scanned:

[0067] After completing the dependency analysis of the current global variable, the system will return to step S1 and continue to traverse the next global variable. The whole process will be repeated until all variables in the global variable list are scanned and a data relationship table is generated.

[0068] It can be seen from the technical solutions provided by the above embodiments of the present invention that the present invention proposes a set of programmer-like recognition rules, which are intended to simulate the recognition process of source code elements by human programmers. These rules not only improve the accuracy of recognition, but also enhance the intelligence of the system. The method of the present invention can clarify the calling and data transmission methods between modules, thereby improving the maintainability and scalability of the system.

[0069] Additional aspects and advantages of the present invention will be given in part in the following description, which will become obvious from the following description, or may be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0071] Figure 1 A flowchart of a process for identifying a statement block in a Linux kernel source code provided by an embodiment of the present invention;

[0072] Figure 2 A flowchart for automatically generating a relationship table between data and modules provided in an embodiment of the present invention;

[0073] Figure 3 A flowchart for automatically generating a relationship table between modules provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0074] The embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and cannot be interpreted as limiting the present invention.

[0075] It will be understood by those skilled in the art that, unless expressly stated, the singular forms "one", "said", and "the" used herein may also include plural forms. It should be further understood that the term "comprising" used in the specification of the present invention refers to the presence of the features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof. It should be understood that when we refer to an element as being "connected" or "coupled" to another element, it may be directly connected or coupled to the other element, or there may be intermediate elements. In addition, the "connection" or "coupling" used herein may include wireless connection or coupling. The term "and / or" used herein includes any unit and all combinations of one or more associated listed items.

[0076] It will be understood by those skilled in the art that, unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as those generally understood by those skilled in the art in the art to which the present invention belongs. It should also be understood that terms such as those defined in common dictionaries should be understood to have meanings consistent with the meanings in the context of the prior art, and will not be interpreted with idealized or overly formal meanings unless defined as herein.

[0077] To facilitate understanding of the embodiments of the present invention, several specific embodiments will be further explained below with reference to the accompanying drawings, and each embodiment does not constitute a limitation on the embodiments of the present invention.

[0078] The present invention can deeply understand the structure of Linux kernel source code, modularize the structure of Linux kernel source code, decompose Linux kernel source code into blocks such as comments, function prototypes, global variables, user-defined data types and macro definitions, and each block can be used as a module. By automatically analyzing the relationship between modules of Linux kernel source code, developers can better grasp the complex dependencies within the program.

[0079] Set programmer-like rule definitions for each statement block, as shown below:

[0080] The rule for comment blocks is defined as follows: if two consecutive forward slashes ( / / ) appear in the area outside the quotation marks, then until the end of the line, it is a single-line comment block. If a forward slash and an asterisk ( / *) appear consecutively in the area outside the quotation marks, and there must be a closed terminator, that is, consecutive asterisks and forward slashes (* / ), then it is a multi-line comment block.

[0081] The rule for function statement blocks is defined as follows: a statement block that meets the conditions in the global scope ends with a semicolon (;), and before the semicolon is a pair of parentheses. The content in the pair of parentheses is the parameter type plus the parameter variable list and can be empty. This is a function declaration statement block. A statement block that meets the conditions in the global scope ends with a right curly brace (}), and the content in the pair of curly braces is the function body. Before the pair of curly braces is a pair of parentheses. The content in the pair of parentheses is the parameter type plus the parameter variable list and can be empty. This is a function definition statement block.

[0082] The rule for global variable statement blocks is defined as follows: a statement block in the global domain that meets the conditions, ends with a semicolon, and is preceded by a variable name or a value assigned to the variable, is a global variable statement block.

[0083] The rules for custom data type statement blocks are defined as follows: a statement block in the global scope that meets the conditions, ends with a semicolon, is preceded by a structure variable name or a pair of curly braces, and contains the keywords struct, enum, union, and typedef is a custom data type statement block.

[0084] The rule of macro definition block is defined as follows: a block of statements in the global domain that meets the conditions, whose first character is a pound sign (#), and whose next non-empty string in the line is the word define, is a macro definition block.

[0085] The flowchart of a process for identifying a statement block in a Linux kernel source code provided by an embodiment of the present invention is as follows: Figure 1 As shown, the processing steps include the following:

[0086] Step S1, overall scanning: perform a preliminary scan of all source files in the Linux kernel source code in order to enter the files for detailed analysis and proceed to step S2.

[0087] Step S2: symbol level preprocessing.

[0088] 1) Initialize the symbol stack: Create a symbol stack to track the nesting levels of symbols such as brackets and quotation marks.

[0089] 2) Scanning and symbol matching criteria (used to guide the source code scanning and symbol matching related processing in step S3).

[0090] a) Bracket matching: Scan each line in the file and maintain a symbol stack to match parentheses (), square brackets [], and curly brackets {}. Whenever a left bracket is encountered, its position is pushed into the stack; when a right bracket is encountered, the stack is popped and a match is ensured.

[0091] b) Quote matching: Scan and match double quotes "" and single quotes "". Whenever a left quote is encountered, the position of the left quote is pushed into the stack to ensure the integrity of the string literal and avoid misjudging the content in the quotes as part of the code structure.

[0092] c) Quote matching takes precedence over bracket matching: If a left quote is encountered first, it is processed as a quote match, that is, the brackets between the left and right quotes are treated as ordinary characters.

[0093] d) Quote nesting matching: Match according to the first left quote type encountered, that is, any quotes between the first left quote and its corresponding right quote will be treated as ordinary characters.

[0094] e) Nested symbol matching in comment blocks: Any symbol appearing in a comment block, including various brackets and quotation marks, will be treated as ordinary characters.

[0095] Go to step S3.

[0096] Step S3, line-by-line analysis: Scan each line in the file line by line to identify specific programming constructs.

[0097] 1) Annotation recognition:

[0098] When / / appears in a line, read to the end of the line, identify it as a comment block, and jump to step S4.

[0099] When / * appears in a line, the reading continues to the next * / , and the content of this paragraph is a comment, and then jumps to step S4.

[0100] 2) Macro definition identification:

[0101] When the first character of a line is # and it is followed by define after skipping whitespace, it is recorded as a macro definition block. If the line ends with \, the next line is read until a non-\ character is encountered, the macro definition block is completely recorded, and the process jumps to step 4.

[0102] 3) Custom data type identification:

[0103] When the typedef, struct, union or enum keyword is detected, the content is read continuously until a segment is encountered, and this segment of content is recorded as a user-defined data type statement block, and the process jumps to step S4.

[0104] 4) Variable and function identification:

[0105] Detect possible variable types or return value types (such as void, bool, int, etc.) and enter the variable and function judgment process:

[0106] a) If the text does not contain matching parentheses (), the text is recorded as a global variable statement block.

[0107] b) If the text contains paired parentheses (), it is considered a function statement block. If the ending character is a semicolon, it is recorded as a function declaration.

[0108] c) If the end character is a left brace {, which is the beginning of the function body, symbol matching starts from the current left brace { until the end brace} is encountered, and this section of text is recorded as a function statement block.

[0109] Jump to step S4.

[0110] Step S4, return to scanning: After completing the above steps, return to step S3 and continue scanning the file until all the file contents are read.

[0111] After the identification and recording of the basic statement blocks of the Linux kernel source code are completed, the present invention further realizes the automatic extraction and arrangement of function statement blocks and global variable statement blocks. First, by analyzing the function declarations and definitions in the Linux kernel source code, a complete function prototype list is generated. The list contains information such as the name of the function, the return value type, the parameter type and the parameter name. At the same time, the present invention also scans and extracts the global variables in the Linux kernel source code to automatically generate a global variable list. The generated global variable list records in detail the key information such as the attributes, data types and initial values ​​of each global variable. On this basis, the present invention automatically generates a list of inclusion relationships between header files by analyzing the header files referenced in each source code file.

[0112] Based on the function prototype list, global variable list and header file inclusion relationship list generated above, the present invention can systematically establish the mutual relationship between modules and clarify the function call and dependency relationship between modules. In addition, by analyzing the parameter transfer situation in the function prototype and the use of global variables, the present invention can derive the association relationship between modules and data, including the module's read and write operations on global data, and the processing method of local data during function calls. By analyzing data elements such as variables and structures, the relationship diagram between data and data is automatically constructed to clarify the dependency and sharing mechanism between data elements.

[0113] An automatic generation process of a relationship table between data and modules provided by an embodiment of the present invention Figure 2 As shown, the processing includes the following:

[0114] Step S1, traverse the function prototype list.

[0115] The system traverses the identified function prototype list to determine the definition location of each function. After completing the location, it proceeds to step S2.

[0116] Step S2, traverse the header files of the source code.

[0117] The system analyzes the header file calling relationship in the source code file, retrieves the referenced header file, and continues to obtain the declaration position of the variable and function by retrieving the variable table and the function prototype table. After completion, it enters step S3.

[0118] Step S3, traverse the function definition.

[0119] The system parses the function definition and performs two types of traversal work:

[0120] 1) Traverse function calls:

[0121] The system analyzes the definition of each function, traverses the called functions, and calls the function prototype table and header file

[0122] relationship, determine the location of the called function, and record the calling relationship between functions in the inter-module relationship table.

[0123] 2) Traverse variable calls:

[0124] The system traverses the variables used in the function definition, locks the called global variables through the global variable table and header file calling relationship, excludes local variables, and records the data interaction relationship between modules in the data and module relationship table.

[0125] Step S4: Return to the function prototype list and continue scanning.

[0126] After completing the traversal of the current function definition, the system returns to the function prototype list, continues to scan the next function, and repeats steps S2 and S3 until all function prototypes are traversed, and finally generates a complete module-to-module relationship table and a data-to-module relationship table.

[0127] An automatic generation process of a relationship table between modules provided by an embodiment of the present invention Figure 3 As shown, the processing includes the following:

[0128] Step S1, traverse the global variable list.

[0129] The process starts by traversing the list of global variables identified in the system. The system checks the definition and usage of each global variable in turn, analyzes their interaction with other modules, and enters step S2.

[0130] Step S2: traverse global variables in the source code file.

[0131] Traverse the source code files to find the definition and usage locations of global variables in each file. This step aims to determine the specific location of each global variable in the code so as to further analyze its usage and dependency relationship, and then proceed to step S3.

[0132] Step S3: Check whether the global variable has a dependency relationship with other variables.

[0133] After finding a global variable, the system will determine whether the variable has a dependency relationship with other global variables. This dependency may be manifested in mutual calls, assignments, or modifications between global variables. If a dependency is found, it will enter process 4; if not, it will directly jump to step S2 and continue to traverse the next global variable.

[0134] Step S4: record the dependency relationship between the global variable and other global variables.

[0135] If the system finds that there is a dependency relationship between global variables, it will record it in the data relationship table and go to step S5.

[0136] Step S5: The global variable list is scanned.

[0137] After completing the dependency analysis of the current global variable, the system will return to process 1 and continue to traverse the next global variable. The entire process will be repeated until all variables in the global variable list have been scanned. Finally, a complete data relationship table is generated.

[0138] Since then, the present invention has realized a comprehensive analysis of source code modules, data structures and their interrelationships, greatly improving the developer's ability to understand the source code logical structure and providing an important reference for subsequent code maintenance and optimization.

[0139] In summary, compared with existing static analysis tools that can only perform surface syntax checking and error detection, the embodiments of the present invention can deeply understand the logical structure of the Linux kernel source code. By automatically identifying statement blocks such as function prototypes, global variables, custom data types and macros, and analyzing these modules and their relationships, developers can fully grasp the complex module dependencies and data interactions in the code. The present invention automatically generates the calling relationship between modules, the association between modules and data, and the dependency between data through a modular analysis method. Developers can use the present invention to easily analyze module dependencies and data flows in complex systems, which helps to understand the global structure of the code and optimize the overall design of the program.

[0140] The present invention can systematically analyze the entire Linux kernel source code without human intervention through a fully automated analysis process and output structured analysis results. Developers can quickly find the required information through query tools, greatly improving work efficiency.

[0141] Those skilled in the art can understand that the accompanying drawings are only schematic diagrams of an embodiment, and the modules or processes in the accompanying drawings are not necessarily required to implement the present invention.

[0142] It can be known from the description of the above implementation methods that those skilled in the art can clearly understand that the present invention can be implemented by means of software plus a necessary general hardware platform. Based on such an understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which can be stored in a storage medium such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in the various embodiments of the present invention or certain parts of the embodiments.

[0143] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device or system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. The device and system embodiments described above are merely schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative labor.

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

Claims

1. The automatic analysis method of Linux kernel source code is characterized by: include: Set a rule definition for each statement block, and decompose the Linux kernel source code into a comment statement block, a function statement block, a global variable statement block, a user-defined data type statement block, and a macro definition statement block according to the rule definition, wherein the function statement block includes a function declaration statement block and a function definition statement block; Take each statement block as a module and analyze the relationship table between modules and the relationship table between data and modules.

2. The method according to claim 1, characterized in that: The rule definition for setting each statement block includes: each statement block includes a comment statement block, a function statement block, a global variable statement block, a user-defined data type statement block and a macro definition statement block, and the function statement block includes a function declaration statement block and a function definition statement block; The rule for comment blocks is defined as follows: if two consecutive forward slashes ( / / ) appear in the area outside the quotation marks, the line to the end of the line is a single-line comment block; if a forward slash and an asterisk ( / *) appear consecutively in the area outside the quotation marks, and there must be a closed end symbol, that is, consecutive asterisks and forward slashes (* / ), it is a multi-line comment block; The rule of function statement block is defined as follows: a statement block that meets the above conditions in the global scope ends with a semicolon (;), and there is a pair of parentheses before the semicolon. The content in the pair of parentheses is the parameter type plus the parameter variable list and can be empty, which is a function declaration statement block; a statement block that meets the above conditions in the global scope ends with a right curly brace (}), and the content in the pair of curly braces is the function body. There is a pair of parentheses before the pair of curly braces. The content in the pair of parentheses is the parameter type plus the parameter variable list and can be empty, which is a function definition statement block; The rule for global variable statement blocks is defined as follows: a statement block in the global domain that meets the conditions, ends with a semicolon, and is preceded by a variable name or a value assigned to the variable, is a global variable statement block; The rule for a custom data type statement block is defined as follows: a statement block in the global scope that meets the above conditions, ends with a semicolon, is preceded by a structure variable name or a pair of curly braces, and contains the keywords struct, enum, union, and typedef is a custom data type statement block; The rule of macro definition block is defined as follows: a block of statements in the global domain that meets the conditions, whose first character is a pound sign (#), and whose next non-empty string in the line is the word define, is a macro definition block.

3. The method according to claim 2, characterized in that The decomposition of the Linux kernel source code into comment statement blocks, function statement blocks, global variable statement blocks, user-defined data type statement blocks and macro definition statement blocks according to the rule definition includes: Step S1, perform a preliminary scan on all source files in the Linux kernel source code, and proceed to step S2; Step S2: symbol level preprocessing: 1) Create a symbol stack, which includes a nested level of tracking bracket and quotation mark symbols; 2) Scanning and symbol matching criteria: a) Bracket matching: Scan each line in the file and maintain a symbol stack to match parentheses (), square brackets [], and curly brackets {}. Whenever a left bracket is encountered, the position of the left bracket is pushed onto the stack; when a right bracket is encountered, the right bracket is popped from the stack to ensure a match; b) Quote matching: Scan and match double quotes "" and single quotes "", and whenever a left quote is encountered, push the position of the left quote into the stack to ensure the integrity of the string literal; c) Quote matching takes precedence over bracket matching: if a left quote is encountered first, it is processed as a quote match, that is, the brackets between the left and right quotes are treated as ordinary characters; d) Quote nesting matching: Matches the first left quote type encountered, that is, any quotes between the first left quote and its corresponding right quote will be treated as ordinary characters; e) Nested symbol matching in comment blocks: Any symbol appearing in a comment block, including brackets and quotation marks, will be treated as ordinary characters; Go to step S3; Step S3, scanning each line in the source file line by line to identify a specific programming construct; 1) Annotation recognition: When / / appears in a line, read to the end of the line, identify it as a comment block, and jump to step S4; When / * appears in a line, continue reading to the next * / , which is a comment, and then jump to step S4; 2) Macro definition identification: When the first character of a line is # and it is followed by define after skipping the blank character, it is recorded as a macro definition statement block. If the line ends with \, the next line is read continuously until a non-\ character is encountered. The macro definition statement block is completely recorded and the process jumps to step S4. 3) Custom data type identification: When the typedef, struct, union, or enum keyword is detected, the content continues to be read until a semicolon is encountered. This section of content is recorded as a custom data type statement block, and jumps to step S4; 4) Variable and function identification: Detect possible variable types or return value types and enter the variable and function judgment process: a) If the text does not contain matching brackets (), the text is recorded as a global variable statement block; b) If the text contains paired brackets (), it is considered a function statement block. If the ending character is a semicolon, it is recorded as a function declaration. c) If the end character is a left brace {, which is the beginning of the function body, then symbol matching starts from the current left brace { until the end brace} is encountered, and this section of text is recorded as a function statement block; Jump to step S4; Step S4, return to scanning: After completing the above steps, return to step S3 and continue scanning the source file until all the contents of the source file are read.

4. The method according to claim 2 or 3, characterized in that: The method of treating each statement block as a module and analyzing the relationship table between modules and the relationship table between data and modules includes: Step S1, traverse the function prototype list: The system traverses the identified function prototype list to determine the definition location of each function. After completing the location, it proceeds to step S2; Step S2, traverse the header file of the source code: The system analyzes the header file calling relationship in the source code file, retrieves the referenced header file, and continues to retrieve the variable table and function prototype table to obtain the declaration position of the variable and function, and then enters step S3; Step S3, traverse function definition: The system parses the function definition and performs two types of traversal work 1) Traverse function calls: The system analyzes the definition of each function, traverses the called functions, and calls the function prototype table and header file Relationship, determine the location of the called function, and record the calling relationship between functions in the inter-module relationship table; 2) Traverse variable calls: The system traverses the variables used in the function definition, locks the called The global variables used are excluded, and the data interaction relationship between modules is recorded in the data and module In the relationship table; Step S4, return to the function prototype list and continue scanning: After completing the traversal of the current function definition, the system returns to the function prototype list, continues to scan the next function, and repeats steps S2 and S3 until all function prototypes are traversed to generate the module relationship table and the data and module relationship table.

5. The method according to claim 4, characterized in that The method further comprises: Step S1, traverse the global variable list: Starting from the list of global variables identified in the traversal system, the definition and usage of each global variable are checked in turn, and their interaction relationship with other modules is analyzed, and then step S2 is entered; Step S2, traverse the global variables in the source code file: Traverse the source code files, find the definition and usage location of the global variables in each file, determine the specific location of each global variable in the code, and enter step S3; Step S3: Check whether the global variable has dependencies with other variables: After finding the global variable, determine whether the global variable has a dependency relationship with other global variables. This dependency relationship may be manifested in mutual calling, assignment or modification between global variables. If a dependency relationship is found, go to step S4; if not, jump directly to step S2 and continue to traverse the next global variable; Step S4: record the dependency relationship between the global variable and other global variables: If the system finds that there is a dependency relationship between global variables, it will record it in the data relationship table and go to step S5; Step S5: The global variable list is scanned: After completing the dependency analysis of the current global variable, the system will return to step S1 and continue to traverse the next global variable. The whole process will be repeated until all variables in the global variable list are scanned and a data relationship table is generated.

Images