Kernel debugging method and device

Abstract

The embodiment of the invention relates to the technical field of computers, and discloses a kernel debugging method and device, and the method comprises the steps: obtaining the dependency relationship of all kernel modules in a linux system; determining a debugging loading sequence of each kernel module based on the dependency relationship; on the basis of the debugging loading sequence, loading the kernel modules in the target debugging environment in sequence; monitoring the loading state of the kernel module, and recording abnormal information; and adjusting a debugging loading sequence according to the abnormal information, so that each kernel module performs kernel debugging in the target debugging environment based on the adjusted debugging loading sequence. By applying the technical scheme of the invention, the debugging efficiency and effect of each kernel module in the linux system can be improved.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of computer technology, and particularly to a kernel debugging method and device. Background Art

[0002] As an open-source operating system widely used, the debugging of the Linux kernel is crucial for the stability and performance optimization of the system. However, the complexity of the Linux kernel makes the debugging work quite challenging. In related technologies, for the debugging of the Linux kernel, customized Linux kernel debugging tools are usually adopted. However, in the debugging environment, these tools usually cause the system to hang or fail to run properly due to improper loading order of kernel modules, thus affecting the efficiency and effect of debugging. Summary of the Invention

[0003] In view of the above problems, the embodiments of the present invention provide a kernel debugging method and device.

[0004] According to one aspect of the embodiments of the present invention, a kernel debugging method is provided, which is applied to a Linux system. The method includes: obtaining the dependency relationships of kernel modules in the Linux system; determining the debugging loading order of each kernel module based on the dependency relationships; sequentially loading each kernel module in a target debugging environment based on the debugging loading order; monitoring the loading status of the kernel modules and recording abnormal information; and adjusting the debugging loading order according to the abnormal information, so that each kernel module performs kernel debugging in the target debugging environment based on the adjusted debugging loading order. Through the above process, the debugging efficiency and effect of each kernel module in the Linux system can be improved.

[0005] In an alternative embodiment, obtaining the dependency relationships of kernel modules in the Linux system includes:

[0006] obtaining the configuration files of the kernel modules and obtaining the module names of each kernel module based on the configuration files;

[0007] reading the corresponding metadata based on the module names;

[0008] analyzing the dependency fields in the metadata to obtain the names of dependent modules;

[0009] obtaining the dependency relationships of each kernel module in the Linux system based on the names of the dependent modules.

[0010] In an alternative embodiment, obtaining the module names of each kernel module based on the configuration files includes:

[0011] reading the definition blocks of each kernel module in the configuration file;

[0012] extracting the module names of the kernel modules based on the name tags in the definition blocks.

[0013] In an alternative embodiment, obtaining the module names of each kernel module based on the configuration file further includes:

[0014] Obtaining the duplicate names in the module names, and marking the kernel modules with duplicate names as conflicting modules;

[0015] Counting the conflict positions and quantities of the conflicting modules, and generating corresponding error reports and configuration check reminder messages based on the conflict positions and quantities to remind the user to check the configuration file based on the error reports.

[0016] In an alternative embodiment, obtaining the duplicate names in the module names and marking the kernel modules with duplicate names as conflicting modules includes:

[0017] Constructing a name set based on the module names;

[0018] Recording the number of occurrences of each module name in the name set through a hash table;

[0019] If the number of occurrences of any module name is greater than 1, marking the kernel module corresponding to the module name as a conflicting module.

[0020] In an alternative embodiment, counting the conflict positions and quantities of the conflicting modules, and generating corresponding error reports and configuration check reminder messages based on the conflict positions and quantities to remind the user to check the configuration file based on the error reports includes:

[0021] Summarizing the names and occurrence positions of the conflicting modules into a conflict list;

[0022] Generating corresponding error content based on the conflict list;

[0023] Obtaining the number of characters of the error content;

[0024] If the number of characters is greater than the character threshold, generating an error summary based on the error content;

[0025] Generating corresponding error reports and configuration check reminder messages based on the error summary to remind the user to check the configuration file based on the error report file.

[0026] In an alternative embodiment, determining the debug loading order of each kernel module based on the dependency relationship includes:

[0027] Constructing a dependency graph based on the dependency relationship;

[0028] Sorting the dependency graph through a topological sorting algorithm to obtain a dependency sorting result;

[0029] Determining the debug loading order of each kernel module based on the dependency sorting result.

[0030] In an alternative embodiment, constructing a dependency graph based on dependencies includes:

[0031] Create a directed acyclic graph;

[0032] Add dependency nodes in the directed acyclic graph based on the module names of each kernel module;

[0033] Add directed edges between the dependency nodes based on the dependencies;

[0034] Construct a dependency graph based on the dependency nodes and the directed edges.

[0035] In an alternative embodiment, constructing a dependency graph based on dependencies further includes:

[0036] If the number of directed edges is greater than the square root of the number of dependency nodes, re-verify the dependencies based on a target verification strategy;

[0037] Adjust the dependency nodes and the directed edges based on the verified dependencies to obtain adjusted dependency nodes and adjusted directed edges;

[0038] Construct a dependency graph based on the adjusted dependency nodes and the adjusted directed edges.

[0039] According to another aspect of the embodiments of the present invention, there is provided a kernel debugging device applied to a Linux system, including: a relationship acquisition module for acquiring the dependencies of each kernel module in the Linux system; an order determination module for determining the debugging loading order of each kernel module based on the dependencies; a kernel loading module for sequentially loading each kernel module in a target debugging environment based on the debugging loading order; an exception recording module for monitoring the loading status of the kernel module and recording exception information; and a kernel debugging module for adjusting the debugging loading order according to the exception information so that each kernel module performs kernel debugging in the target debugging environment based on the adjusted debugging loading order. Through the above modules, the debugging efficiency and effect of each kernel module in the Linux system can be improved.

[0040] According to another aspect of the embodiments of the present invention, there is provided a computer device, including: a processor, a memory, a communication interface, and a communication bus. The processor, the memory, and the communication interface complete mutual communication through the communication bus; the memory is used for storing at least one executable instruction, and the executable instruction causes the processor to perform the operations of the foregoing kernel debugging method.

[0041] According to yet another aspect of the embodiments of the present invention, there is provided a computer-readable storage medium storing at least one executable instruction, and the executable instruction causes a computer device / device to perform the operations of the foregoing kernel debugging method.

[0042] According to another aspect of an embodiment of the present invention, there is provided a computer program product including computer instructions for causing a computer to perform the operations of the kernel debugging method according to the first aspect or any corresponding embodiment thereof as described above.

[0043] The above description is only an overview of the technical solutions of the embodiments of the present invention. In order to be able to understand the technical means of the embodiments of the present invention more clearly, it can be implemented according to the content of the description. And in order to make the above and other purposes, features and advantages of the embodiments of the present invention more obvious and understandable, the following specifically describes the embodiments of the present invention. Description of the Drawings

[0044] The drawings are only used to illustrate the embodiments and are not considered to be a limitation of the present invention. Moreover, throughout the drawings, the same reference numerals are used to represent the same components. In the drawings:

[0045] Figure 1 A flowchart showing a kernel debugging method provided by the present invention is shown;

[0046] Figure 2 Another flowchart showing a kernel debugging method provided by the present invention is shown;

[0047] Figure 3 Another flowchart showing a kernel debugging method provided by the present invention is shown;

[0048] Figure 4 A structural diagram showing a kernel debugging device provided by the present invention is shown;

[0049] Figure 5 A structural diagram showing a computer device provided by the present invention is shown. Detailed Embodiments

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

[0051] Figure 1 A flowchart showing a first embodiment of a kernel debugging method of the present invention is shown and is applied to a Linux system. As Figure 1 shown, the method includes the following steps:

[0052] Step 110, obtaining the dependency relationships of each kernel module in the Linux system.

[0053] Specifically, the dependency relationships among the kernel modules in the Linux system are realized by statically analyzing the kernel source code of the Linux system. Specifically, first, the kernel source code of the Linux system is parsed to extract the dependency relationship information among the kernel modules, and a corresponding dependency graph is constructed. Then, when developing the target software, according to the function to be developed and the corresponding target main thread, the kernel modules related to the target main thread are found in the dependency graph, and then the kernel modules to be debugged and their dependency relationships are determined, so as to accurately obtain the dependency relationships among the kernel modules in the Linux system and provide strong support for subsequent kernel debugging work.

[0054] Furthermore, when parsing the kernel source code of the Linux system, existing source code parsing tools or self-written parsing scripts can be used to deeply analyze the header files, source files, and call relationships among modules in the kernel source code to ensure the accuracy and integrity of the extracted dependency relationship information. At the same time, in order to visually display the dependency relationships among the kernel modules, the constructed dependency graph can adopt various forms of expression such as tree diagrams and network diagrams, which are convenient for developers to understand and analyze.

[0055] Step 120: Determine the debug loading order of each kernel module based on the dependency relationship.

[0056] Specifically, when determining the debug loading order of each kernel module based on the dependency relationship, the dependency levels and call relationships among the kernel modules need to be comprehensively considered. First, for independent kernel modules without dependency relationships, they can be directly debugged and loaded. Second, for kernel modules with dependency relationships, they need to be debugged and loaded in order from the lowest to the highest dependency level to ensure that all the kernel modules on which a certain kernel module depends have been correctly loaded and initialized before loading this kernel module. In addition, according to the cyclic dependency situation among the kernel modules, the module design or loading strategy needs to be adjusted to avoid the loading failure problem caused by cyclic dependencies. Through a reasonable debug loading order, the correct operation and mutual cooperation of each kernel module in the target software can be ensured.

[0057] In an optional implementation manner, the kernel modules can also be sorted based on preset kernel module loading rules. That is, before the kernel starts, the loading priorities of each module are determined according to certain logic and rules. These rules can be formulated based on multiple factors such as dependency relationships, initialization time, or security. Through this pre-sorting, it can be ensured that key modules are loaded first, reducing the possibility of loading conflicts and failures. For example, assume that a kernel module depends on another basic module, then in the preset rules, the loading priority of the basic module will be higher to ensure that the dependency relationship is satisfied.

[0058] In addition, when formulating the kernel module loading rules, the stability and performance of the system also need to be considered. For some modules that have a greater impact on system stability, a higher loading priority can be set to ensure that the system can quickly enter a stable state. At the same time, for modules with a longer initialization time or larger resource consumption, their loading timing can be reasonably arranged to avoid resource tension or response delay during startup. In terms of security, modules involving security verification or protection functions can be set to be loaded with a high priority to effectively resist external attacks or the intrusion of malicious software. By comprehensively considering various factors and formulating scientific and reasonable kernel module loading rules, the overall performance and security of the system can be further improved.

[0059] Step 130: Based on the debugging loading order, load each kernel module in the target debugging environment in sequence.

[0060] Specifically, during the process of loading each kernel module in sequence in the target debugging environment based on the debugging loading order, the loading status of each kernel module can be monitored in real time to ensure that each kernel module can be correctly loaded and run. At the same time, relevant information during the loading process, such as loading time, loading result, etc., can also be recorded for subsequent analysis and optimization. If any problems are encountered during the loading process, such as unmet module dependencies, loading failures, etc., the loading process is immediately stopped and corresponding error prompts are given to facilitate developers to locate and solve the problems in a timely manner. In addition, developers can adjust the loading order and loading parameters according to actual needs to meet the debugging requirements in different scenarios, so as to ensure that the kernel modules are correctly loaded in the target debugging environment according to the predetermined order, laying a solid foundation for subsequent system debugging and testing work.

[0061] In an optional implementation manner, when applying the sorting result to the actual loading process after completing the sorting of kernel modules, it can be managed by the kernel scheduler to ensure that each module is loaded in the established order. During this process, the target debugging environment provides necessary support tools, such as log recording, breakpoint debugging, etc., to help developers better observe and control the loading behavior of kernel modules. For example, the development team set up a target debugging environment on a virtual machine, used KVM (Kernel-based Virtual Machine) and QEMU (Quick Emulation), and executed the loading process of kernel modules in this target debugging environment to facilitate observing and debugging every detail of kernel startup.

[0062] Step 140: Monitor the loading status of the kernel module and record abnormal information.

[0063] As described above, by continuously monitoring the loading status of the kernel module loading process, relevant information can be captured and recorded immediately when problems occur. This not only helps to discover problems in a timely manner but also provides important data support for subsequent problem analysis.

[0064] In an alternative embodiment, the above abnormal information may include the name of the kernel module that failed to load, error codes, occurrence time, context environment, etc. For example, the result of each kernel module load is recorded through the kernel logging system dmesg, and the klogd process periodically checks for error messages in the log to ensure that any abnormalities can be quickly detected and handled.

[0065] In addition, to improve the stability of the system, when it is detected that a certain kernel module fails to load, the module can also be tried to be reloaded, or other appropriate recovery measures can be taken according to the error code and context environment. For example, if the loading failure is caused by unmet dependencies, the missing dependent modules can be tried to be loaded first, and then the target module can be reloaded, so as to minimize the impact on the entire system caused by the failure of the kernel module to load.

[0066] Step 150, adjust the debug loading order according to the abnormal information, so that each kernel module performs kernel debugging in the target debug environment based on the adjusted debug loading order.

[0067] Specifically, when adjusting the debug loading order, the abnormal information can be analyzed to determine which kernel module loading orders may cause conflicts or failures, and the loading order can be adjusted accordingly. For example, if a certain kernel module depends on services or resources provided by other modules, the system will ensure that these dependent modules are loaded before the target module. If the abnormal information indicates that a certain kernel module fails to load due to dependency issues, the adjusted debug loading order can give priority to loading other modules on which the module depends to ensure that the dependencies are met. In addition, if a module still fails after multiple attempts to load, the system can mark it as "unloadable" and skip this module during subsequent debugging to avoid unnecessary waiting and errors.

[0068] Through the above method, loading failures caused by improper loading order can be effectively avoided, thereby improving the efficiency and success rate of kernel debugging. At the same time, by recording the loading order and debugging results after each adjustment, it can provide reference and basis for subsequent kernel development and debugging.

[0069] In an alternative embodiment, when an exception occurs during the loading of a kernel module, an adjustment mechanism can also be triggered, that is, re-evaluate the module's dependencies and other influencing factors, and then optimize and adjust the loading order to solve the problem without stopping the entire system, improving the stability and robustness of the system. For example, assume that a hang occurs when loading a certain network driver module. After analysis, it is found that there is a problem of initialization resource contention in this module. At this time, by adjusting the configuration file or using a dedicated debugging tool, the loading order of this module can be postponed backward, allowing other critical modules that do not involve resource contention to be loaded first, thereby restoring the normal operation of the system. This can not only solve the current hang problem but also prevent similar situations that may occur in the future.

[0070] The kernel debugging method of the embodiments of the present invention effectively solves various problems that may occur during the loading of kernel modules, especially the system hang problem caused by improper loading order, and greatly improves the efficiency and success rate of kernel debugging through reasonable sorting, step-by-step loading, real-time monitoring, and dynamic adjustment.

[0071] Figure 2 The flowchart of another embodiment of the kernel debugging method of the present invention is shown, which is applied to the Linux system. As Figure 2 shown, the method includes the following steps:

[0072] Step 210, obtain the dependencies of each kernel module in the Linux system.

[0073] Specifically, the above step 210 includes:

[0074] Step 2101, obtain the configuration file of the kernel module, and obtain the module name of each kernel module based on the configuration file.

[0075] In an alternative embodiment, when obtaining the module name of each kernel module based on the configuration file, the definition blocks of each kernel module in the configuration file can be read; the module name of the kernel module is extracted based on the name tags in the definition blocks. That is, by reading the kernel module information from the configuration file of the kernel module, the module name of each kernel module is extracted, so as to determine the specific kernel module that needs to be processed subsequently.

[0076] Specifically, the configuration file can be read line by line or by segment, and each module definition block in the configuration file can be separated. The module name is extracted based on the name tags in the definition block. In this process, the keyword field representing the module name is searched for and extracted from the read module definition block. The field is usually called the name tag. For example, in the configuration file, if there is an entry as follows: alias sound-slot-0 snd-card-0, then this step needs to be able to recognize that the name tag here is snd-card-0.

[0077] In an alternative embodiment, it is also possible to obtain duplicate names in the module names and mark the kernel modules with duplicate names as conflicting modules; count the conflict positions and quantities of the conflicting modules, and generate corresponding error reports and configuration check reminder messages based on the conflict positions and quantities to remind the user to check the configuration file based on the error report.

[0078] Specifically, after extracting the module names of all kernel modules, they need to be compared to check whether multiple modules are given the same name. In the case of finding the same name, these modules are regarded as conflicting modules and are specially marked. If two or more definition entries use the same name tag, these entries are identified as conflicting.

[0079] If the number of conflicting modules C is greater than 0, record the conflicting modules and prompt the user to check the configuration file. Here, C refers to the total number of all detected conflicting modules. The value range of the total number of conflicting modules is theoretically greater than or equal to zero, but the most ideal state is that no conflict occurs (C = 0). The significance of this rule setting is to judge whether there are potential problems in the configuration file by detecting whether C > 0, and timely remind the user to pay attention to ensure the stability and predictability of the system. When it is found that C > 0, the program will not only record all the conflicting module information in the log, but also give a clear warning message to guide the user to review and correct the corresponding configuration items, thus helping to avoid loading failures or other unknown behaviors caused by configuration errors.

[0080] In an alternative embodiment, when obtaining duplicate names in the module names and marking the kernel modules with duplicate names as conflicting modules, a name set can be constructed based on the module names; record the number of occurrences of each module name in the name set through a hash table; if the number of occurrences of any module name is greater than 1, mark the kernel module corresponding to the module name as a conflicting module.

[0081] Specifically, first traverse all the extracted module names to construct a name set, aiming to obtain all module names from each kernel module of the system to ensure no omission, and put these module names into a set to obtain the name set. The purpose of the name set is to facilitate subsequent processing and search operations. For example, the module names extracted from the Linux kernel may include Module A, Module B, and Module C, and they are put into a set {Module A, Module B, Module C}.

[0082] Next, when using a hash table to record the number of occurrences of each name, the hash table is an efficient data structure for storing and querying data, which can quickly count the number of occurrences of each module name (name) in the set. In the specific implementation, while traversing the set of module names, each name and its number of occurrences can be stored in the hash table. For example, if the set of module names is {Module A, Module B, Module A, Module C}, the hash table record result is: {Module A: 2, Module B: 1, Module C: 1}. If the number of occurrences F of a certain name is greater than 1, it is marked as a conflicting module. Here, the parameter F represents the number of occurrences of the module name recorded in the hash table, and its value range is non-negative integers. When F > 1, it means that the module name appears at least twice and should be marked as a conflicting module. For example, in the hash table {Module A: 2, Module B: 1, Module C: 1} in the previous step, the number of occurrences of Module A is 2, so it is marked as a conflicting module.

[0083] Subsequently, output a list of all conflicting modules and generate an error report, aiming to collect all the module names marked as conflicting to form a list and generate a detailed error report for developers to further handle these problems. Assume that Module A is determined to be a conflicting module, then the final output list of conflicting modules is [Module A], and a corresponding error report is generated, which details which module names have duplicate problems in the report to help developers quickly locate and solve the problems.

[0084] In summary, throughout the process, by traversing the set of module names, using a hash table to record the number of occurrences, marking conflicting modules, and generating error reports, the uniqueness of module names in the system is ensured, and the stability and reliability of the system are improved. F > 1 is based on the assumption that module names should be unique under normal circumstances. If the same name appears multiple times, it means there are potential conflicts that need special attention and handling.

[0085] In an alternative implementation, when counting the conflict positions and quantities of conflicting modules and generating corresponding error reports and configuration check reminder messages based on the conflict positions and quantities to remind the user to check the configuration file based on the error report, the names and occurrence positions of the conflicting modules can be summarized into a conflict list; corresponding error content is generated based on the conflict list; the number of characters of the error content is obtained; if the number of characters is greater than the character threshold, an error summary is generated based on the error content; and corresponding error reports and configuration check reminder messages are generated based on the error summary to remind the user to check the configuration file based on the error report file.

[0086] Specifically, when summarizing the conflicting module names and their occurrence locations into a list, the system first traverses all the modules in the current running environment to check their compatibility. Once it is found that there are compatibility issues between certain modules, the names of these modules and their locations in the memory or file system are recorded, aiming to provide a detailed data basis for subsequent processing. When generating a detailed error report based on the list, the data generated in the previous step can be utilized to create a text containing the detailed information of the conflicting modules, including but not limited to module versions, reasons for conflicts, and possible solutions. This can help system administrators or developers quickly locate the root cause of the problem and take measures to fix it.

[0087] Next, save the generated error report to the location predefined by the user or configuration file, such as a file in a specific directory, for relevant personnel to consult at any time. While ensuring the security and reliability of data storage, it also facilitates subsequent problem tracking and historical comparison. If the report length L exceeds the set maximum length M, the first M characters are intercepted and an ellipsis is added. Here, L represents the total number of characters of the actually generated error report, and M is the preset maximum allowable length value. Generally, it is recommended to set it between 2000 and 5000 characters, and the specific optimal value can be flexibly adjusted according to actual application requirements. The purpose of this operation is to prevent the error report file from being too large, resulting in tight storage space or difficult transmission, while ensuring that the key content of the report is retained.

[0088] For example, assume that when debugging the kernel of a certain Linux system, it is detected that two network driver modules cannot be loaded simultaneously due to different implementation details. Based on this list, the system generates a detailed error report, explaining why the two drivers cannot coexist and giving suggestions on reconfiguring or uninstalling one of the modules. The report is finally saved to the / var / log directory of the system. Considering security and access efficiency, the file size is controlled to not exceed 3000 characters. In addition, L may reach or even exceed 3000. If M is set to 3000, the exceeded part will be represented by an ellipsis to ensure that the file does not exceed the limited maximum size. This setting effectively balances the requirements of information integrity and resource management.

[0089] Step 2102, read the corresponding metadata based on the module name.

[0090] Among them, the above metadata usually contains various attributes and information of the module. Analyze the dependency fields in the metadata and record the names of the dependent modules. This refers to extracting the dependency information of the specified module from the metadata file. According to the recorded names of the dependent modules, recursively parse the information of each dependent module until all dependent modules are parsed. Here, D represents the number of direct dependent modules of the current module during each parsing. Usually, the initial value of D is the number of direct dependencies of this module. When the recursive parsing is completed, D should be 0, indicating that there are no more dependencies to parse.

[0091] Through the above steps, the information of the kernel module and all its dependencies can be obtained comprehensively and in detail, which helps to accurately locate problems and optimize performance during the debugging and maintenance of the kernel.

[0092] Step 2103: Analyze the dependency fields in the metadata to obtain the names of the dependent modules.

[0093] Step 2104: Based on the names of the dependent modules, obtain the dependency relationships of each kernel module in the Linux system.

[0094] Step 220: Determine the debug loading order of each kernel module based on the dependency relationships.

[0095] For details, please refer to Figure 1 Step 120 of the illustrated embodiment, which will not be elaborated here.

[0096] Step 230: Based on the debug loading order, load each kernel module in the target debug environment in sequence.

[0097] For details, please refer to Figure 1 Step 130 of the illustrated embodiment, which will not be elaborated here.

[0098] Step 240: Monitor the loading status of the kernel module and record the exception information.

[0099] For details, please refer to Figure 1 Step 140 of the illustrated embodiment, which will not be elaborated here.

[0100] Step 250: Adjust the debug loading order according to the exception information so that each kernel module performs kernel debugging in the target debug environment based on the adjusted debug loading order.

[0101] For details, please refer to Figure 1 Step 150 of the illustrated embodiment, which will not be elaborated here.

[0102] In summary, the kernel debugging method according to the embodiments of the present invention obtains the dependency relationships of various kernel modules in the Linux system; determines the debugging loading order of each kernel module based on the dependency relationships; successively loads each kernel module in the target debugging environment based on the debugging loading order; monitors the loading status of the kernel modules and records the exception information; adjusts the debugging loading order according to the exception information, so that each kernel module performs kernel debugging in the target debugging environment based on the adjusted debugging loading order, thereby improving the debugging efficiency and effect of each kernel module in the Linux system.

[0103] Figure 3 The flowchart of another embodiment of the kernel debugging method of the present invention is shown, which is applied to the Linux system. As Figure 3 shown, the method includes the following steps:

[0104] Step 310, obtain the dependency relationships of various kernel modules in the Linux system.

[0105] For details, please refer to Figure 2 Step 210 of the embodiment shown, which will not be elaborated here.

[0106] Step 320, determine the debugging loading order of each kernel module based on the dependency relationships.

[0107] Specifically, the above step 320 includes:

[0108] Step 3201, construct a dependency graph based on the dependency relationships.

[0109] Step 3202, sort the dependency graph through a topological sorting algorithm to obtain a dependency sorting result.

[0110] Step 3203, determine the debugging loading order of each kernel module based on the dependency sorting result.

[0111] In an alternative embodiment, when sorting kernel modules based on preset kernel module loading rules, first, obtain the dependency information of the kernel modules. This means determining other modules that each module depends on by analyzing the configuration files or other metadata of the kernel modules. This information is usually included in the module's configuration file or the dependency list generated during the compilation process. For example, by reading the file, the dependency relationships between the modules can be obtained. Next, construct a dependency graph based on the dependency information to transform the obtained dependency information into a graphical representation, that is, each module is a node in the graph, and the dependency relationships between the modules are represented as edges. For example, if module A depends on module B, then in the dependency graph, there will be a directed edge from A to B. This graph structure enables the subsequent sorting algorithm to execute effectively. Then, use a topological sorting algorithm to sort the dependency graph. The topological sorting algorithm is applicable to directed acyclic graphs (DAGs), and it can arrange the nodes in a certain order so that all the prerequisite nodes of each node are arranged in front of it. Specifically, common topological sorting algorithms such as the Kahn algorithm or depth-first search (DFS) can be applied to this scenario. For example, in one embodiment, the Kahn algorithm can be used to process the dependency graph to obtain an ordered module list that conforms to the dependency relationships. Finally, adjust the loading order of the kernel modules according to the sorting result to ensure that the modules with correct dependencies are loaded. The last step is to rearrange the loading order of the kernel modules according to the sorting result after the topological sorting is completed. This can ensure that all modules are loaded sequentially according to the correct dependency relationships, avoiding problems caused by improper loading order. For example, assume that the module loading order after topological sorting is B -> C -> A. Then, in actual loading, module B will be loaded first, followed by module C, and finally module A, which can ensure that all dependency relationships are correctly processed.

[0112] It can be understood that through the above steps, not only can the effective management of the kernel module loading order be achieved, the kernel debugging process be optimized, but also it helps to improve the stability and reliability of the system, thereby simplifying the work burden of developers and maintainers.

[0113] In an alternative embodiment, when constructing a dependency graph based on dependencies, a directed acyclic graph can be created first; add dependency nodes in the directed acyclic graph based on the module names of each kernel module; add directed edges between the dependency nodes based on the dependencies; and construct a dependency graph based on the dependency nodes and directed edges.

[0114] In an alternative embodiment, when constructing a dependency graph based on dependencies, if the number of directed edges is greater than the square root of the number of dependency nodes, the dependencies are re-verified based on the target verification strategy; based on the verified dependencies, the dependency nodes and directed edges are adjusted to obtain adjusted dependency nodes and adjusted directed edges; and a dependency graph is constructed based on the adjusted dependency nodes and adjusted directed edges.

[0115] When creating a directed acyclic graph (DAG), first establish a data structure that represents a series of nodes and the relationships between them, where these relationships are unidirectional and there are no cyclic paths. In this data structure, nodes represent specific kernel modules or functions, and directed edges represent the dependencies from one module to another. For example, when debugging the Linux kernel, an empty DAG can be created to record how the modules call or depend on each other.

[0116] When adding nodes to the graph based on dependency information, the corresponding modules or functions can be added as nodes in the DAG according to the actual dependencies of the kernel modules or functions. Specifically, assuming that the part of the kernel being analyzed contains four key modules, this step is to add these four modules as independent nodes to the empty DAG to facilitate the subsequent establishment of the connection relationships between them.

[0117] When adding directed edges between nodes according to dependencies, the corresponding nodes in the graph can be connected using directed edges according to the actual dependencies. The direction of the directed edge indicates the direction of the call or dependency. For example, when dealing with network stack issues, if it is found that the TCP module depends on the IP module to work, a directed edge should be drawn in the direction from the TCP module node to the IP module node to indicate the existence of this dependency relationship.

[0118] Furthermore, if the number of directed edges E is greater than the square root of the number of nodes N, additional dependency verification is performed to ensure the correctness of the graph, where E represents the number of directed edges and N represents the number of nodes. The formula sqrt{N} < E here mainly serves to initiate an additional dependency verification mechanism when the graph becomes relatively complex (there are extremely many connections between nodes) to ensure that the quality of the final debugging results is not affected by false positives. In this inequality, N can increase from 1 to several thousand or even more; while E needs to be a non-negative integer. There is no absolute standard for the optimal setting under this condition as it depends on the specific system size and complexity, but the overall goal is to reduce possible incorrect configurations. When this condition is met, it means there are too many complex connections or potential circular dependencies in the system, and it is necessary to further verify the validity and necessity of the dependencies to avoid difficulties in debugging or a decline in system performance caused by logical errors. For example, when it is detected that the number of directed edges in a large Linux kernel system far exceeds the expected value, certain redundant or abnormal dependencies are successfully discovered through triggering the additional verification process, thereby simplifying the entire kernel structure and improving the debugging efficiency and stability.

[0119] To ensure the accuracy of the constructed dependency graph, additional dependency verification is required to check for potential errors or missing dependencies in the graph. By comparing the dependency descriptions in the kernel source code or documentation, it can be verified whether each node and its connections in the graph are accurate. If any inconsistencies are found, it is necessary to return to the previous steps for correction until it is ensured that all dependencies are correctly represented in the graph. This verification process not only improves the accuracy of the dependency graph but also provides a more reliable basis for subsequent debugging work.

[0120] During the verification process, various technical means can be adopted, such as static code analysis and dynamic testing, to comprehensively check the correctness of the dependencies. Static code analysis can automatically identify and extract the dependencies between modules by scanning the kernel source code and then compare them with the dependency graph. Dynamic testing, on the other hand, monitors the process of module loading and unloading during system operation to observe whether the actual dependencies are consistent with those shown in the graph. The combined use of these verification means can greatly improve the accuracy and reliability of the dependency graph construction. At the same time, to ensure the effectiveness and efficiency of the verification process, we also need to continuously optimize and adjust the verification strategy to adapt to kernel systems of different scales and complexities.

[0121] In addition, to ensure the efficient and accurate construction of the dependency graph, a phased verification strategy is also adopted during the construction process. In the initial phase, that is, the phase of collecting dependency relationship information, basic data integrity and consistency checks are carried out to avoid introducing incorrect or contradictory information into subsequent graph construction steps. As the dependency graph is gradually constructed, every time a node or an edge is added, the local verification logic is immediately triggered to ensure that the newly added elements do not disrupt the overall structure of the graph, such as checking whether a loop is formed or whether the defined dependency rules are violated.

[0122] After the dependency graph is completely constructed, in addition to the above-mentioned additional verification based on the ratio of the number of directed edges to the number of nodes, a comprehensive graph traversal check is also carried out to finally confirm the correctness of the graph. This step not only includes the verification of the existence and connectivity of nodes and edges, but also can deeply check the semantic correctness of the dependency relationships, such as ensuring that there are no circular dependencies and no missing dependencies. Through these multi-level verification measures, the accuracy and reliability of the dependency graph can be maximally guaranteed, providing a solid foundation for subsequent kernel debugging work.

[0123] In an alternative implementation, when creating a directed acyclic graph (DAG), the graph structure can be initialized first; all dependency relationships are traversed, and each module is used as a node of the graph; edges are used to connect the nodes with dependency relationships; if there is a circular dependency, that is, a loop R is formed between nodes, the loop nodes are recorded and an exception is thrown, where R represents the loop nodes.

[0124] Initializing the graph structure means creating an initial graph object to prepare the data structure for subsequent operations. This graph object contains an empty set of nodes and an empty set of edges, so that they can be gradually filled in subsequent steps. This step ensures a clear and orderly basic environment, enabling the graph to be effectively constructed and managed.

[0125] All dependency relationships are traversed, and each module is used as a node of the graph. This process requires traversing all modules in the system, identifying the unique identifier of each module, and adding it as a node in the graph to the graph structure. Here, the modules can be system components, functional modules, or kernel modules, etc. The key to this step is to accurately extract and record the information of each module to ensure the integrity of the graph.

[0126] Edges are used to connect the nodes with dependency relationships. During this process, according to the dependency relationships between the modules traversed before, edges are added between the nodes with direct or indirect dependency relationships. For example, assume that module A depends on module B, and module B depends on module C, then corresponding edges will be added between these three modules: A→B and B→C. This form of expressing dependency relationships ensures that the graph can correctly represent the dependency structure in the system.

[0127] If there is a cyclic dependency, i.e., a loop R is formed between nodes, then record the loop nodes and throw an exception. The key here is to detect whether there is a loop in the graph. The existence of a loop will cause the system to malfunction because it will have an infinite cyclic dependency, eventually leading to resource exhaustion or deadlock. The loop can be detected through a topological sorting algorithm or other graph traversal methods. If a loop is found, record all the nodes in the loop and throw an exception to interrupt further graph construction operations. This step ensures that the created graph is acyclic and conforms to the definition of a directed acyclic graph (DAG).

[0128] In one embodiment, assume there is a system for debugging the Linux kernel. The system contains multiple modules, and each module has its own functions and dependencies. Then, add edges according to the dependencies between the modules.

[0129] For the parameter R, which represents a set of nodes forming a loop, it is a set. It ranges from the simplest loop with at least two nodes (such as A → B → A) to complex loops composed of multiple nodes. The optimal value is no loop, i.e., R is an empty set, which can ensure the normal construction and use of the graph. The purpose of setting the parameter R is to be able to quickly and accurately identify and handle cyclic dependency problems in the graph, ensuring that the finally generated graph is a valid directed acyclic graph (DAG).

[0130] Next, when obtaining the initial graph structure, an empty set of nodes and an empty set of edges can be created first. This step ensures that there is no data contamination in the initial state and provides a clean starting point for empty nodes and edges. Define node classes and edge classes. Node classes and edge classes usually contain necessary attributes and methods, enabling each component in the graph to correctly represent its function. For example, in a system for debugging the Linux kernel, nodes may represent different kernel modules, and edges may represent call relationships or dependencies between modules. Then, use a hash table to manage nodes and their attributes. By using a hash table, a large number of nodes can be efficiently searched and managed, ensuring quick access to node attributes and related information. In this embodiment, the attributes of nodes can include module names, paths, version information, etc.

[0131] If the size S of the hash table is greater than the total number T of modules, optimization processing is performed to reduce the storage space, where S represents the size of the hash table and T represents the total number of modules. Here, S is a natural number reflecting the number of entries in the hash table; T is also a natural number representing the number of modules in the system. When S > T, it indicates that there is extra space in the hash table, which may lead to resource waste. In this case, the storage can be optimized by deleting unnecessary hash table entries or compressing the hash table. Specifically, after traversing all nodes, it can be checked whether there are extra empty spaces in the hash table and cleaned up. In addition, a hash table with dynamically adjustable size can also be considered to adjust the size of the hash table according to the actual situation, thereby optimizing the storage.

[0132] For example, suppose there is a Linux kernel debugging system with 10 modules, and a hash table capable of accommodating 100 entries is initially created. After initializing the graph structure and adding all nodes, it is found that only 10 nodes are actually used. At this time, S = 100 and T = 10. Obviously, there are a large number of spare entries. To reduce the storage space, the redundant hash table entries can be deleted, or the hash table can be readjusted to a more appropriate size, such as adjusted to a size that can only accommodate 10 entries. Through such optimization, the performance and efficiency of the system can be effectively improved.

[0133] Next, in the process of using the hash table to manage nodes and their attributes, since the hash table is an efficient management tool, it can improve the data retrieval speed, especially in the case of dealing with a large number of nodes and their attributes. The specific steps are as follows:

[0134] First, traverse all nodes and add them to the hash table. This step ensures that all nodes in the system can be effectively managed and retrieved. For example, suppose there are multiple kernel module nodes in the system, and each node contains information such as the name, version, and status of the module. After traversing these nodes, they will be inserted into the hash table one by one.

[0135] Secondly, assign a unique identifier to each node. This identifier is used to distinguish different nodes and ensure that each node has a unique corresponding position in the hash table. For example, in a specific embodiment, the unique identifier can be generated by combining the name and type of the node. Specifically, if the name of the node is netfilter and the type is module, the unique identifier may be netfilter_module.

[0136] Furthermore, record the attributes of the nodes, such as name, type, etc. This step ensures that the information of each node is accurately recorded, facilitating subsequent queries and operations. For example, the node netfilter may have the attributes: name netfilter, type module, status active.

[0137] Finally, if the conflict rate H in the hash table is greater than the preset threshold Q, the hash table is reinitialized with a larger hash table capacity to improve the lookup efficiency. Here, H represents the conflict rate of the hash table, that is, the proportion of the number of conflicts caused by the same hash address in the hash table; Q represents the preset conflict rate threshold, usually set between 0.1 and 0.3, and the specific optimal value depends on the performance requirements of the actual application scenario. For example, assume that the current hash table conflict rate H = 0.35, which exceeds the preset threshold Q = 0.3. Then, reinitialization will be triggered, and the capacity of the new hash table can be twice the original, for example, increased from 1024 to 2048. After reinitializing the hash table, all nodes recalculate their hash values and are inserted into the new hash table, thereby reducing the conflict rate and improving the performance and stability of the system.

[0138] Through the above steps, nodes and their attributes can be efficiently managed and queried during Linux kernel debugging, ensuring the operation efficiency and reliability of the system.

[0139] Step 330: Based on the debugging loading order, load each kernel module in the target debugging environment in sequence.

[0140] For details, please refer to Figure 1 Step 130 of the illustrated embodiment, which will not be elaborated here.

[0141] Step 340: Monitor the loading status of the kernel module and record the exception information.

[0142] For details, please refer to Figure 1 Step 140 of the illustrated embodiment, which will not be elaborated here.

[0143] Step 350: Adjust the debugging loading order according to the exception information, so that each kernel module performs kernel debugging in the target debugging environment based on the adjusted debugging loading order.

[0144] For details, please refer to Figure 1 Step 150 of the illustrated embodiment, which will not be elaborated here.

[0145] The kernel debugging method of the present invention arranges all the kernel modules to be loaded in an orderly manner through the preset kernel module loading rules; then, loads these kernel modules one by one in the sorted order in the target debugging environment; during this process, the system will monitor the loading situation of each kernel module in real time to promptly capture any possible abnormal situations and record these abnormal situations in detail; finally, based on the recorded exception information, further optimize and adjust the loading order of the kernel modules to avoid or solve problems such as system hangs caused by improper loading order.

[0146] This method aims to solve the situation of system instability or even crash caused by improper loading order of kernel modules in a systematic and step-by-step manner. First, by reasonably planning the loading order of kernel modules, it ensures that modules with clear dependencies can be loaded in the correct order, thereby reducing the failure probability caused by missing dependencies. Then, a real-time monitoring mechanism is introduced during the actual loading process, which can not only immediately detect and record potential loading failures, but also provide valuable first-hand information for subsequent problem diagnosis. Most importantly, based on these real-time recorded abnormal information. At the same time, through a feedback mechanism to dynamically adjust the loading order, it not only improves the debugging efficiency, but also significantly reduces the phenomenon of system hangs, thus ensuring the smoothness and efficiency of the Linux kernel debugging process.

[0147] Figure 4 The structural schematic diagram of an embodiment of a kernel debugging device of the present invention is shown, which is applied to the Linux system. As Figure 4 shown, the device includes:

[0148] A relationship acquisition module 410, configured to acquire the dependency relationships of each kernel module in the Linux system;

[0149] An order determination module 420, configured to determine the debugging loading order of each kernel module based on the dependency relationships;

[0150] A kernel loading module 430, configured to sequentially load each kernel module in the target debugging environment based on the debugging loading order;

[0151] An exception recording module 440, configured to monitor the loading status of the kernel module and record abnormal information;

[0152] A kernel debugging module 450, configured to adjust the debugging loading order according to the abnormal information, so that each kernel module performs kernel debugging in the target debugging environment based on the adjusted debugging loading order.

[0153] In an optional implementation manner, the relationship acquisition module 410 includes:

[0154] A configuration file acquisition sub-module, configured to acquire the configuration file of the kernel module and obtain the module name of each kernel module based on the configuration file;

[0155] A metadata reading sub-module, configured to read the corresponding metadata based on the module name;

[0156] A metadata analysis sub-module, configured to analyze the dependency fields in the metadata to obtain the dependency module name;

[0157] A dependency relationship acquisition sub-module, configured to acquire the dependency relationships of each kernel module in the Linux system based on the dependency module name.

[0158] In an alternative embodiment, the relationship acquisition module 410 further includes:

[0159] A definition block reading sub-module, configured to read the definition blocks of each kernel module in the configuration file;

[0160] A module name extraction sub-module, configured to extract the module name of the kernel module based on the name tag in the definition block.

[0161] In an alternative embodiment, the relationship acquisition module 410 further includes:

[0162] A conflict module marking sub-module, configured to obtain the duplicate names in the module name and mark the kernel modules with duplicate names as conflict modules;

[0163] A conflict information statistics sub-module, configured to count the conflict positions and quantities of the conflict modules, and generate corresponding error reports and configuration check reminder messages based on the conflict positions and quantities, so as to remind the user to check the configuration file based on the error reports.

[0164] In an alternative embodiment, the conflict module marking sub-module is specifically configured to construct a name set based on the module name; record the number of occurrences of each module name in the name set through a hash table; if the number of occurrences of any module name is greater than 1, mark the kernel module corresponding to the module name as a conflict module.

[0165] In an alternative embodiment, the conflict information statistics sub-module is specifically configured to summarize the names and occurrence positions of the conflict modules into a conflict list; generate corresponding error content based on the conflict list; obtain the number of characters of the error content; if the number of characters is greater than the character threshold, generate an error summary based on the error content; generate corresponding error reports and configuration check reminder messages based on the error summary, so as to remind the user to check the configuration file based on the error report file.

[0166] In an alternative embodiment, the sequence determination module 420 includes:

[0167] A dependency graph construction sub-module, configured to construct a dependency graph based on the dependency relationship;

[0168] A dependency graph sorting sub-module, configured to sort the dependency graph through a topological sorting algorithm to obtain a dependency sorting result;

[0169] A loading sequence determination sub-module, configured to determine the debug loading sequence of each kernel module based on the dependency sorting result.

[0170] In an alternative embodiment, the dependency graph construction sub-module is specifically configured to create a directed acyclic graph; add dependency nodes in the directed acyclic graph based on the module names of each kernel module; add directed edges between the dependency nodes based on the dependency relationships; and construct a dependency graph based on the dependency nodes and the directed edges.

[0171] In an alternative embodiment, the dependency graph construction sub-module is specifically configured to, if the number of directed edges is greater than the square root of the number of dependency nodes, re-verify the dependency relationships based on a target verification strategy; adjust the dependency nodes and the directed edges based on the verified dependency relationships to obtain adjusted dependency nodes and adjusted directed edges; and construct a dependency graph based on the adjusted dependency nodes and the adjusted directed edges.

[0172] The further functional descriptions of the above-mentioned various modules and units are the same as those in the corresponding method embodiments above, and will not be elaborated here.

[0173] Through the above device and its components, the technical solution provided by the embodiments of the present invention has the following advantages:

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

[0175] FIG. 1, one processor 510 is taken as an example.

[0176] Among them, the memory 520 stores instructions that can be executed by at least one processor 510, so that the at least one processor 510 executes the method shown in the above embodiments.

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

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

[0179] The computer device further includes a communication interface 530 for the computer device to communicate with other devices or communication networks.

[0180] An embodiment of the present invention also provides a computer-readable storage medium, and the storage medium stores at least one executable instruction. When the executable instruction runs on a computer device / kernel debugging device, the computer device / kernel debugging device executes the kernel debugging method in any of the above method embodiments.

[0181] An embodiment of the present invention also provides a computer program product, including computer instructions for causing a computer to execute the kernel debugging method in the first aspect or any corresponding embodiment thereof.

[0182] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. In addition, embodiments of the present invention are not directed to any particular programming language.

[0183] In the description provided herein, numerous specific details are set forth. It will be understood, however, that embodiments of the invention may be practiced without these specific details. Similarly, in order to streamline the present invention and assist in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of the invention, various features of the embodiments of the invention are sometimes grouped together in a single embodiment, figure, or description thereof. Wherein, the claims following the detailed description are hereby expressly incorporated into the detailed description, where each claim itself serves as a separate embodiment of the invention.

[0184] Those skilled in the art can understand that the modules in the devices in the embodiments can be adaptively changed and arranged in one or more devices different from the embodiments. The modules or units or components in the embodiments can be combined into one module or unit or component, and in addition, they can be divided into multiple sub-modules or sub-units or sub-components. Except that at least some of such features and / or processes or units are mutually exclusive.

[0185] It should be noted that the above embodiments illustrate rather than limit the invention, and those skilled in the art can design alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of elements or steps not listed in the claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The present invention can be implemented by means of hardware including several different elements and by means of a suitably programmed computer. In a unit claim listing several devices, several of these devices may be embodied by the same item of hardware. The use of the words first, second, and third, etc. does not denote any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

Claims

1. A kernel debugging method, characterized in that: Applied to the Linux system, the method includes: Obtain the dependency relationship of each kernel module in the Linux system; Determine the debugging loading order of each of the kernel modules based on the dependency relationship; Based on the debugging loading sequence, sequentially loading each of the kernel modules in the target debugging environment; Monitor the loading status of the kernel module and record abnormal information; The debugging loading sequence is adjusted according to the abnormal information, so that each kernel module performs kernel debugging in the target debugging environment based on the adjusted debugging loading sequence.

2. The method according to claim 1, characterized in that The obtaining of the dependency relationship of each kernel module in the Linux system includes: Obtaining a configuration file of the kernel module, and obtaining a module name of each kernel module based on the configuration file; Read corresponding metadata based on the module name; Analyze the dependency field in the metadata to obtain the dependency module name; Based on the dependent module name, the dependency relationship of each kernel module in the Linux system is obtained.

3. The method according to claim 2, characterized in that The obtaining the module name of each kernel module based on the configuration file includes: Read the definition block of each kernel module in the configuration file; A module name of the kernel module is extracted based on the name tag in the definition block.

4. The method according to claim 2, characterized in that: The obtaining the module name of each kernel module based on the configuration file further includes: Obtaining duplicate names from the module names, and marking the kernel modules with duplicate names as conflicting modules; The conflicting positions and quantities of the conflicting modules are counted, and corresponding error reports and configuration check reminder information are generated based on the conflicting positions and quantities, so as to remind the user to check the configuration file based on the error report.

5. The method according to claim 4, characterized in that The obtaining of duplicate names in the module names and marking the kernel modules with duplicate names as conflicting modules includes: Building a name set based on the module name; Record the number of times each module name in the name set appears by using a hash table; If the number of occurrences of any module name is greater than 1, the kernel module corresponding to the module name is marked as a conflicting module.

6. The method according to claim 4, characterized in that The counting of conflicting positions and numbers of the conflicting modules, and generating corresponding error reports and configuration check reminder information based on the conflicting positions and numbers to remind the user to check the configuration file based on the error report, includes: Summarize the names and occurrence locations of the conflicting modules into a conflict list; Generate corresponding error content based on the conflict list; Get the number of characters in the error content; If the number of characters is greater than the character threshold, generating an error summary based on the error content; A corresponding error report and configuration check reminder information are generated based on the error summary to remind the user to check the configuration file based on the error report file.

7. The method according to claim 2, characterized in that Determining the debugging loading order of each kernel module based on the dependency relationship includes: Building a dependency graph based on the dependency relationship; Sorting the dependency graph by a topological sorting algorithm to obtain a dependency sorting result; The debugging loading order of each of the kernel modules is determined based on the dependency sorting result.

8. The method according to claim 7, characterized in that The step of constructing a dependency graph based on the dependency relationship includes: Create a directed acyclic graph; Adding a dependency node in the directed acyclic graph based on the module name of each of the kernel modules; Adding directed edges between the dependent nodes based on the dependency relationship; The dependency graph is constructed based on the dependency nodes and the directed edges.

9. The method according to claim 8, characterized in that The constructing a dependency graph based on the dependency relationship further includes: If the number of the directed edges is greater than the square root of the number of the dependent nodes, re-verifying the dependency relationship based on the target verification strategy; Based on the verified dependency relationship, the dependency node and the directed edge are adjusted to obtain an adjusted dependency node and an adjusted directed edge; The dependency graph is constructed based on the adjustment dependency nodes and the adjustment directed edges.

10. A kernel debugging device, characterized in that: Applied to the Linux system, the device comprises: A relationship acquisition module is used to acquire the dependency relationship of each kernel module in the Linux system; An order determination module, used for determining the debugging loading order of each of the kernel modules based on the dependency relationship; A kernel loading module, used to sequentially load each of the kernel modules in a target debugging environment based on the debugging loading sequence; An exception recording module, used to monitor the loading status of the kernel module and record exception information; The kernel debugging module is used to adjust the debugging loading sequence according to the abnormal information, so that each kernel module performs kernel debugging in the target debugging environment based on the adjusted debugging loading sequence.

Images