Kernel module dependency relationship detection method based on static scanning and electronic device

Abstract

Embodiments of the present application provide a kernel module dependency relationship detection method based on static scanning and an electronic device. It relates to the technical field of embedded operating systems. The method comprises: obtaining module identification information of each driver module and each hardware matching identifier supported by each driver module; obtaining a device tree file, parsing each device node in the device tree file, extracting the matching identifier supported by each device node, and extracting the dependency relationship between each device node; matching each hardware matching identifier corresponding to each driver module with the matching identifier of each device node to determine the correspondence relationship between each driver module and each device node; based on the correspondence relationship between each driver module and each device node and the dependency relationship between each device node, a driver module dependency relationship table is determined, which is used to indicate the loading order between each driver module. The accurate detection of the dependency relationship can be realized.

Description

Technical Field

[0001] This application relates to the field of embedded operating system technology, and in particular to a kernel module dependency detection method and electronic device based on static scanning. Background Technology

[0002] Embedded operating systems (such as Android) are widely used in mobile terminals, the Internet of Things, and automotive electronics. When the system starts up, it needs to load multiple kernel modules in a strict order to initialize various hardware devices. The dependencies and loading order between driver modules directly affect the reliability of system startup.

[0003] Currently, kernel module dependency detection typically employs dynamic detection schemes. This involves running the system on a real physical device or dedicated test board, then executing scripts to collect runtime device node information and reference relationship fields, thereby inferring dependencies between modules. However, this method struggles to comprehensively cover all dependencies, leading to omissions in the dependency detection results. Summary of the Invention

[0004] This application provides a kernel module dependency detection method and electronic device based on static scanning, which can be used to achieve accurate detection of dependencies.

[0005] In a first aspect, embodiments of this application provide a kernel module dependency detection method based on static scanning, including:

[0006] Obtain the module identification information of each driver module, as well as the hardware matching identifiers supported by each driver module;

[0007] Obtain the device tree file, parse each device node in the device tree file, extract the matching identifiers supported by each device node, and extract the dependencies between each device node;

[0008] Match the hardware matching identifiers corresponding to each driver module with the matching identifiers of each device node to determine the correspondence between each driver module and each device node;

[0009] Based on the correspondence between each driver module and each device node, as well as the dependency relationship between each device node, a driver module dependency table is determined. The driver module dependency table is used to indicate the loading order between each driver module.

[0010] In one possible implementation, obtaining the module identification information of each driver module includes:

[0011] Obtain the system startup configuration file, which includes module identification information for all driver modules that need to be loaded;

[0012] Extract the module identification information of each driver module from the system startup configuration file.

[0013] In one possible implementation, the hardware matching identifiers supported by each driver module are obtained, including:

[0014] Obtain the compilation metadata files of each driver module and determine the source code file path information based on the compilation metadata files. The compilation metadata files are used to indicate the source code file path information corresponding to each driver module.

[0015] Based on the source code file path information, obtain the source code files corresponding to each driver module;

[0016] Extract the hardware matching identifiers supported by each driver module from the source code files corresponding to each driver module.

[0017] In one possible implementation, the dependencies between device nodes are extracted, including:

[0018] Extract the parent-child dependencies between device nodes. These dependencies indicate the hierarchical dependencies between parent and child device nodes in the device tree; and / or,

[0019] Extract the reference dependencies between device nodes. The reference dependencies are used to indicate the resource reference relationship between one device node and another device node.

[0020] In one possible implementation, extracting the reference dependencies between device nodes includes:

[0021] If a device node references another device node that itself references other device nodes, recursively resolve all levels of reference relationships until there are no further references.

[0022] In one possible implementation, after extracting the dependencies between device nodes, the method further includes:

[0023] Based on the dependencies between each device node, a device node dependency table is determined. The device node dependency table is used to indicate the dependencies between each device node.

[0024] In one possible implementation, the method further includes:

[0025] Generate a driver module to device node mapping table. This table records the association between each driver module and its matching device nodes.

[0026] Determine the driver module dependency table, including:

[0027] Based on the driver module and device node correspondence table, the dependencies between device nodes in the device node dependency table are converted into dependencies between driver modules, generating a driver module dependency table.

[0028] In one possible implementation, the driver module dependency table is also used for at least one of the following:

[0029] Verify whether the preset loading order of each driver module at system startup is consistent with the loading order indicated by the driver module dependency table. If they are inconsistent, output a prompt message; and / or,

[0030] Write to the system startup configuration file to instruct the system to load each driver module in the order indicated by the driver module dependency table during system startup.

[0031] Secondly, embodiments of this application provide a kernel module dependency detection device based on static scanning, comprising: an acquisition module, a first processing module, a second processing module, and a determination module, wherein,

[0032] The acquisition module is used to acquire the module identification information of each driver module and the hardware matching identifiers supported by each driver module.

[0033] The first processing module is used to obtain the device tree file, parse each device node in the device tree file, extract the matching identifiers supported by each device node, and extract the dependency relationships between each device node.

[0034] The second processing module is used to match the hardware matching identifiers corresponding to each driver module with the matching identifiers of each device node to determine the correspondence between each driver module and each device node.

[0035] The determination module is used to determine the driver module dependency table based on the correspondence between each driver module and each device node, as well as the dependency relationship between each device node. The driver module dependency table is used to indicate the loading order between each driver module.

[0036] In one possible implementation, the acquisition module is specifically used for:

[0037] Obtain the system startup configuration file, which includes module identification information for all driver modules that need to be loaded;

[0038] Extract the module identification information of each driver module from the system startup configuration file.

[0039] In one possible implementation, the acquisition module is specifically used for:

[0040] Obtain the compilation metadata files of each driver module and determine the source code file path information based on the compilation metadata files. The compilation metadata files are used to indicate the source code file path information corresponding to each driver module.

[0041] Based on the source code file path information, obtain the source code files corresponding to each driver module;

[0042] Extract the hardware matching identifiers supported by each driver module from the source code files corresponding to each driver module.

[0043] In one possible implementation, the first processing module is specifically used for:

[0044] Extract the parent-child dependencies between device nodes. These dependencies indicate the hierarchical dependencies between parent and child device nodes in the device tree; and / or,

[0045] Extract the reference dependencies between device nodes. The reference dependencies are used to indicate the resource reference relationship between one device node and another device node.

[0046] In one possible implementation, the first processing module is specifically used for:

[0047] If a device node references another device node that itself references other device nodes, recursively resolve all levels of reference relationships until there are no further references.

[0048] In one possible implementation, the kernel module dependency detection device based on static scanning further includes a third processing module, which is used for:

[0049] Based on the dependencies between each device node, a device node dependency table is determined. The device node dependency table is used to indicate the dependencies between each device node.

[0050] In one possible implementation, the third processing module is specifically used for:

[0051] Generate a driver module to device node mapping table. This table records the association between each driver module and its matching device nodes.

[0052] Determine the driver module dependency table, including:

[0053] Based on the driver module and device node correspondence table, the dependencies between device nodes in the device node dependency table are converted into dependencies between driver modules, generating a driver module dependency table.

[0054] In one possible implementation, the driver module dependency table is also used for at least one of the following:

[0055] Verify whether the preset loading order of each driver module at system startup is consistent with the loading order indicated by the driver module dependency table. If they are inconsistent, output a prompt message; and / or,

[0056] Write to the system startup configuration file to instruct the system to load each driver module in the order indicated by the driver module dependency table during system startup.

[0057] Thirdly, embodiments of this application provide an electronic device, including: at least one processor and a memory; the memory stores computer-executable instructions; at least one processor executes the computer-executable instructions stored in the memory, causing at least one processor to execute the kernel module dependency detection method based on static scanning as described in the first aspect and various possible designs of the first aspect.

[0058] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the static scanning-based kernel module dependency detection method described above and various possible designs of the first aspect.

[0059] Fifthly, embodiments of this application provide a computer program product, including a computer program, which, when executed by a processor, implements the static scanning-based kernel module dependency detection method as described in the first aspect and various possible designs of the first aspect.

[0060] In a sixth aspect, embodiments of this application provide a chip, the chip including at least one processor, the processor being configured to execute program instructions to implement the static scanning-based kernel module dependency detection method as described in the first aspect above and various possible designs of the first aspect.

[0061] This application provides a kernel module dependency detection method and electronic device based on static scanning. By using a static scanning mechanism to jointly parse the driver module and device tree file, the matching relationship between the driver module and hardware device can be automatically established during the coding stage without relying on the physical hardware environment. It can also completely extract the dependency relationships between all nodes in the device tree, covering all hardware dependencies, including implicit resource dependencies, and achieving accurate detection of dependencies. This results in the accurate generation of a complete driver module loading order, reducing the possibility of system startup failures caused by missed dependency detection, and improving the iterative efficiency of driver development and the reliability of system startup. Attached Figure Description

[0062] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0063] Figure 1 A flowchart illustrating a kernel module dependency detection method based on static scanning provided in this application;

[0064] Figure 2 A schematic diagram of the structure of the kernel module dependency detection device based on static scanning provided in this application;

[0065] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0066] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0067] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0068] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation portals for users to choose to authorize or refuse.

[0069] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0070] It should be noted that the kernel module dependency detection method and electronic device based on static scanning provided in this application can be used in the field of embedded operating system technology, and can also be used in any field other than the field of embedded operating system technology. The application field of the kernel module dependency detection method and electronic device based on static scanning in this application is not limited.

[0071] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0072] Embedded operating systems (such as Android) are widely used in mobile terminals, the Internet of Things, and automotive electronics. When the system starts up, it needs to load multiple kernel modules in a strict order to initialize various hardware devices. The dependencies and loading order between driver modules directly affect the reliability of system startup.

[0073] Currently, the detection of kernel module dependencies usually adopts a dynamic detection scheme, which involves running the system on a real physical device or a dedicated test board, and then collecting device node information and reference relationship fields generated during runtime by executing scripts, thereby inferring the dependencies between modules.

[0074] However, the aforementioned dynamic detection method has a technical problem: it is difficult to fully cover all dependencies, resulting in omissions in the detection results. It can only identify explicitly declared references, and cannot identify implicit resource dependencies that have not generated relevant reference fields (such as the bus controller's dependency on DMA resources), leading to missed dependency detections and causing system startup failures due to improper loading order.

[0075] To address the aforementioned issues, this application provides a kernel module dependency detection method based on static scanning. This method involves obtaining the module identifier information of each driver module and the hardware matching identifiers supported by each driver module; obtaining a device tree file, parsing each device node in the device tree file, extracting the matching identifiers supported by each device node, and extracting the dependencies between device nodes; matching the hardware matching identifiers corresponding to each driver module with the matching identifiers of each device node to determine the correspondence between each driver module and each device node; and determining a driver module dependency table based on the correspondence between each driver module and each device node, as well as the dependencies between each device node. This driver module dependency table is used to indicate the loading order of each driver module.

[0076] In the above method, the driver module and device tree file are jointly parsed through a static scanning mechanism. The matching relationship between the driver module and the hardware device can be automatically established during the coding stage without relying on the physical hardware environment. The dependency relationship between all nodes in the device tree can be completely extracted, covering all hardware dependencies, including implicit resource dependencies. This enables accurate detection of dependencies, thereby accurately generating the complete driver module loading order. This reduces the possibility of system startup failures caused by missed dependency detection and improves the iterative efficiency of driver development and the reliability of system startup.

[0077] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0078] First, let me explain the terms used in this application:

[0079] A driver module is a loadable program unit in an operating system used to control and manage specific hardware devices. It includes logic for hardware device initialization, data reading and writing, and control instruction execution. The driver module declares the hardware matching identifiers it supports; the operating system uses these identifiers to match and bind the driver module to the specific hardware device.

[0080] Hardware matching identifier: This is a string of information used to uniquely identify the device model or type. It serves as the matching basis between the driver module and the device node, establishing a one-to-one correspondence between them. The driver module declares the hardware matching identifiers it supports, indicating that it can control hardware devices with that identifier. The device node declares its hardware matching identifier, indicating the device model it describes. In this embodiment, the driver module and device node are matched using the hardware matching identifier. Upon successful matching, a correspondence between the driver and the device is established, thereby converting the physical dependencies of the device nodes into loading order dependencies between driver modules.

[0081] A device tree file is a configuration file that uses a tree structure to describe the location, type, attributes, and connection relationships of various physical devices in a hardware platform. It records hardware topology information in text form. Each node in the device tree file corresponds to a physical device or controller, and the node contains a matching identifier for that device and its connection relationships with other devices. In this embodiment, the device tree file is a Device Tree Source (DTS) file, used to pass hardware configuration information to the operating system kernel, allowing the kernel to adapt to different hardware platforms without modifying its code.

[0082] Device nodes are the basic building blocks in a device tree file, describing specific physical devices, bus controllers, clock sources, interrupt controllers, and other hardware resources. Each device node contains attributes such as its name, matching identifier, and dependencies with other nodes. In this embodiment, a device node corresponds to a physical device or controller on the circuit board, and the parent-child relationships and references between device nodes together constitute the complete dependency topology between hardware devices.

[0083] For example, Figure 1 A flowchart illustrating a kernel module dependency detection method based on static scanning provided in this application is shown below. Figure 1 As shown, the method includes:

[0084] S101. Obtain the module identification information of each driver module and the hardware matching identifiers supported by each driver module.

[0085] The execution entity in this application embodiment can be an electronic device or a kernel module dependency detection device based on static scanning installed in an electronic device. The kernel module dependency detection device based on static scanning can be implemented in software or a combination of software and hardware.

[0086] In one possible implementation, each driver module declares one or more hardware matching identifiers it supports in its source code, which indicate which models of hardware devices the driver module can control.

[0087] For example, driver modules are .ko files in the Linux kernel. During system startup, these driver modules must be loaded in the correct order to initialize various hardware devices. For instance, the driver module for an Inter-Integrated Circuit (I2C) bus controller must be loaded before the touchscreen driver module it manages. If the touchscreen driver is loaded before the I2C bus controller driver, the touchscreen driver will fail to initialize due to the inability to communicate with the hardware.

[0088] In some implementations, obtaining the module identification information of each driver module may include:

[0089] Obtain the system startup configuration file, which includes the module identification information of all driver modules that need to be loaded; extract the module identification information of each driver module from the system startup configuration file.

[0090] In one possible implementation, the system startup configuration file includes module identification information for all driver modules that need to be loaded during system startup. The module identification information of each driver module is arranged in the loading order. The system startup configuration file can be read, and the module identification information of each driver module can be extracted line by line.

[0091] In one possible implementation, module identification information refers to identity information used to uniquely identify a driver module. For example, in this embodiment, module identification information can be the filename of the driver module.

[0092] When the driver module is a .ko file in the Linux kernel, the module identification information can be the file name of the .ko file. For example, if the driver module file name is "file name A.ko", its module identification information can be "file name A". As long as it can uniquely distinguish different driver modules, this application does not limit this.

[0093] In one possible implementation, obtaining the system startup configuration file may include: obtaining the configuration file storage path, where the configuration file storage path is the directory where the system startup configuration file is stored, and reading the system startup configuration file from the configuration file storage path.

[0094] In one possible implementation, extracting the module identification information of each driver module from the system startup configuration file may include: reading each line of the system startup configuration file, where each line records the filename of a driver module; extracting the filename of the driver module from each line, removing the suffix from the filename, and obtaining the module identification information of each driver module.

[0095] In this way, by obtaining and parsing the system startup configuration file, all driver modules that need to be loaded when the system starts can be automatically identified without the need for manual specification. This makes the list of driver modules to be detected complete and automatically obtainable, providing a complete input basis for subsequent dependency detection of all driver modules.

[0096] In some implementations, the hardware matching identifiers supported by each driver module are obtained, including:

[0097] Obtain the compilation metadata files of each driver module and determine the source code file path information based on the compilation metadata files. The compilation metadata files are used to indicate the source code file path information corresponding to each driver module. Based on the source code file path information, obtain the source code file corresponding to each driver module. Extract the hardware matching identifiers supported by each driver module from the source code file corresponding to each driver module.

[0098] In one possible implementation, the compilation metadata file refers to a descriptive file automatically generated along with the driver module's object files during the compilation process. The compilation metadata file records the source code file paths used during the driver module's compilation. For example, the compilation metadata file is a .mod file generated by the Linux kernel compilation system, and its name is the same as the driver module's name. For example, when the driver module is camera.ko, its compilation metadata file is camera.mod.

[0099] In one possible implementation, the source code file path information refers to the path where the source code is stored. This can be obtained by compiling the source code files (recorded in the compilation metadata file) into object file path information, and then changing the suffix of the object file path information to the source code file suffix. For example, in the Linux kernel compilation system, each .c source code file is compiled into a corresponding .o object file, and the compilation metadata file (.mod file) records the path information of each .o object file. Since the .o file is compiled from the corresponding .c file, there is a one-to-one correspondence between the two. Therefore, the path of the .c source file can be deduced from the .o file path. For example, the compilation metadata file camera.mod records a path S1 / S2 / S3 / camera.o, which is an object file path. Changing the suffix from .o to .c yields the source code file path information S1 / S2 / S3 / camera.c.

[0100] In one possible implementation, the source code file refers to the original program file written by the driver module developer, containing hardware control logic and hardware matching identifier declarations. For example, the source code file is a .c file (C language source file) used in Linux kernel driver development, which includes the driver module's initialization functions, operation functions, and hardware matching identifier declarations.

[0101] In one possible implementation, obtaining the compilation metadata file of each driver module may include: determining the compilation output directory of each driver module, where the compilation output directory is the storage path for the output object files after the driver module is compiled; and searching for a file with the same name as the module identification information and the suffix .mod in the compilation output directory based on the module identification information of each driver module, and using it as the compilation metadata file of the driver module.

[0102] In one possible implementation, determining the source code file path information based on the compilation metadata file may include: reading the compilation metadata file, extracting the recorded lines of content, determining each line of content as the target file path information, and then replacing the target file extension in the extracted target file path information with the source code file extension to obtain the source code file path information. For example, the compilation metadata file (.mod file) records the path information of the target file (.o file). Replacing the .o extension at the end of the path with the .c extension yields the corresponding source code file path information. For example, the compilation metadata file camera.mod records the target file path as S1 / S2 / S3 / camera.o. Replacing .o with .c yields the source code file path S1 / S2 / S3 / camera.c. When the driver module is compiled from multiple .c files, the compilation metadata file records multiple lines of target file path information; replacing these lines individually yields the complete source code file path information.

[0103] In one possible implementation, obtaining the source code file corresponding to each driver module based on the source code file path information may include: determining the location of the source code file in the file system based on the source code file path information; accessing the location and reading the contents of the source code file.

[0104] In one possible implementation, extracting the hardware matching identifiers supported by each driver module from the source code files corresponding to each driver module can include: performing text scanning on the source code files, matching the declaration syntax of the hardware matching identifiers, and extracting the values ​​of the hardware matching identifiers from the matching results. For example, the source code files of the driver modules declare the hardware matching identifiers they support through the `of_device_id` structure, where the core member is the `compatible` field. Regular expression matching is performed on the source code files to locate the definition of the `of_device_id` structure, and then the value of the `compatible` member is extracted. It is determined whether the member value is a string; if it is a string, the member value is identified as a hardware matching identifier; if it is not a string, the member value is converted to a string, and the converted result is identified as the hardware matching identifier.

[0105] In one possible implementation, the target file path information recorded in the compilation metadata file includes either an absolute path or a relative path. After replacing the target file extension with the source code file extension in the target file path information to obtain the source code file path information, the method further includes: determining whether the source code file path information is an absolute path or a relative path; if it is an absolute path, then directly accessing the corresponding source code file based on the source code file path information; if it is a relative path, then obtaining the path of the current working directory, concatenating the path of the current working directory with the relative path to obtain the complete absolute path of the source code file, and then accessing the corresponding source code file based on the complete absolute path of the source code file.

[0106] In this way, by compiling metadata files, the source code files corresponding to the driver modules can be automatically traced, and hardware matching identifiers can be extracted from the source code. There is no need to manually maintain the mapping relationship between driver modules and hardware matching identifiers. All hardware matching identifiers supported by each driver module can be obtained automatically and completely, reducing omissions or errors that may be caused by manual sorting, and providing reliable basic data for accurate matching with device tree nodes in the future.

[0107] In one possible implementation, when determining the hardware matching identifiers supported by each driver module, a driver identifier mapping table can be established. This table is a data structure or set that records the correspondence between the module identifier information of each driver module and the hardware matching identifiers supported by each driver module. Each record in the table indicates the mapping relationship between a driver module and one or more hardware matching identifiers it supports. The driver identifier mapping table is used to structurally associate each driver module with its supported hardware matching identifiers, serving as the data basis for subsequently matching the hardware matching identifiers of the driver modules with the matching identifiers of the device nodes. During matching, all hardware matching identifiers corresponding to each driver module can be quickly obtained by querying this table, eliminating the need to rescan the source code and improving the efficiency of the matching step.

[0108] S102. Obtain the device tree file, parse each device node in the device tree file, extract the matching identifiers supported by each device node, and extract the dependencies between each device node.

[0109] In one possible implementation, the dependencies between device nodes include parent-child dependencies and reference dependencies.

[0110] In this context, parent-child dependencies indicate the hierarchical dependencies between parent and child device nodes in the device tree. The device tree is organized in a tree structure, with parent nodes representing buses or controllers and child nodes representing devices connected to those buses or controllers. At the hardware level, child devices depend on the communication channels provided by their parent devices; therefore, the parent device must complete its initialization before the child device.

[0111] Reference dependencies indicate how one device node references resources from another device node. In a device tree, one device node may reference hardware resources represented by another device node through attributes, such as clock sources, interrupt controllers, or DMA controllers. The referenced resource node must be initialized before the referrer.

[0112] In one possible implementation, the device tree file can be statically parsed to extract the matching identifiers supported by each device node and the dependencies between device nodes.

[0113] In one possible implementation, obtaining the device tree file may include: obtaining the storage path of the device tree file, where the storage path is the location of the device tree file in the file system; and reading the contents of the device tree file based on the storage path. When the platform contains multiple device tree files (e.g., different hardware configurations correspond to different device tree files), all device tree files can be obtained, and subsequent parsing steps can be performed on each device tree file separately to ensure comprehensive coverage of the dependencies of all hardware configurations.

[0114] In one possible implementation, parsing each device node in the device tree file and extracting the matching identifiers supported by each device node may include: performing syntax parsing on the device tree file to identify each device node in the device tree file; for each identified device node, searching for the matching identifier attribute from the attribute list of the device node, reading the value of the matching identifier attribute as the matching identifier supported by the device node.

[0115] In some implementations, the dependencies between device nodes are extracted, including:

[0116] Extract the parent-child dependency relationships between each device node. The parent-child dependency relationship is used to indicate the hierarchical dependency relationship between parent device nodes and child device nodes in the device tree; and / or, extract the reference dependency relationships between each device node. The reference dependency relationship is used to indicate the resource reference relationship between one device node and another device node.

[0117] In one possible implementation, extracting the parent-child dependency relationships between device nodes may include: parsing the device tree file to identify the hierarchical relationship of each device node in the tree structure; for each device node, determining its direct parent node as its parent device node, and defining the hierarchical relationship between the parent device node and the child device node as the parent-child dependency relationship. The parent device must complete its initialization before the child device.

[0118] In this way, by extracting the parent-child dependencies and reference dependencies between device nodes in the device tree, we can comprehensively cover various dependency types between hardware devices, including both upper and lower level communication channel dependencies and resource reference dependencies between devices. This provides a comprehensive data foundation for generating a complete device node dependency table and reduces the possibility of incomplete detection due to missing dependency types.

[0119] In some implementations, the reference dependencies between device nodes are extracted, including:

[0120] If a device node references another device node that itself references other device nodes, recursively resolve all levels of reference relationships until there are no further references.

[0121] In one possible implementation, since the reference relationships in the device tree may have multiple levels of nesting, that is, another device node referenced by one device node may itself reference other device nodes, this step adopts a recursive parsing method to parse all reference relationships layer by layer until there are no further references, so that all levels of reference dependencies are completely extracted.

[0122] For example, in the device tree, there exists a storage tracer node that references a processor tracer node; this processor tracer node references a CPU node; and this CPU node further references a frequency control node. When extracting the reference dependencies of this storage tracer node, the direct reference to the processor tracer node is first identified. Then, the processor tracer node is recursively parsed to identify its reference to the CPU node. The CPU node is then recursively parsed to identify its reference to the frequency control node. Since the frequency control node has no further references, the recursion terminates. The final extracted complete reference dependency chain contains all four levels of reference relationships.

[0123] In this way, by using recursive parsing, it is possible to penetrate any level of reference nesting in the device tree, completely extract all reference dependency chains, identify multi-level implicit dependencies, further improve the comprehensiveness and accuracy of dependency detection, and reduce loading order errors caused by missing intermediate level dependencies.

[0124] In some implementations, after extracting the dependencies between device nodes, the method also includes:

[0125] Based on the dependencies between each device node, a device node dependency table is determined. The device node dependency table is used to indicate the dependencies between each device node.

[0126] In one possible implementation, a device node dependency table refers to a data structure or data set used to record the dependency relationships between device nodes. The device node dependency table contains multiple records, each indicating other device nodes that a device node depends on. For example, the device node dependency table can be presented in tabular form, with each row recording a device node, its dependent parent device node, and other referenced device nodes, or it can record the dependency mapping relationships between nodes in key-value pairs.

[0127] In one possible implementation, determining the device node dependency table based on the dependencies between device nodes may include: obtaining all parent-child dependencies and all reference dependencies extracted from the parsed device tree file; for each device node, determining the parent device node that the device node depends on and the other device nodes that it references as the device node's dependencies; constructing the device node dependency table using each device node as an index and the dependencies of each device node as the index content; for device nodes that do not have any dependencies, their dependencies can be recorded as empty.

[0128] In this way, by establishing a device node dependency table, the scattered dependencies extracted from the parsed device tree file are centrally organized and stored in a structured manner, providing a clear and complete data foundation for the subsequent conversion of hardware dependencies into driver module dependencies, and improving the accuracy and traceability of the dependency conversion process.

[0129] S103. Match the hardware matching identifiers corresponding to each driver module with the matching identifiers of each device node to determine the correspondence between each driver module and each device node.

[0130] In one possible implementation, the hardware matching identifiers corresponding to each driver module are matched with the matching identifiers of each device node to determine the correspondence between each driver module and each device node. This can include: based on the driver identifier mapping table, traversing each hardware matching identifier supported by each driver module, performing a global search in the matching identifiers of each device node for each hardware matching identifier, and determining the device node corresponding to the matching identifier of the device node that matches the hardware matching identifier as the device node that matches the driver module; and establishing the correspondence between the driver module and the successfully matched device node.

[0131] For example, driver module M is a touchscreen driver module with a hardware matching identifier of the string "hardware matching identifier A". Device node A exists in the device tree file; this device node is a touchscreen device node on the SPI bus, and its matching identifier is also the string "hardware matching identifier A". The hardware matching identifier of driver module M can be compared with the matching identifiers of all device nodes. If the matching identifier of device node A matches, then driver module M is determined to be matched with device node A, meaning driver module M is used to control the touchscreen hardware device described by device node A. After the correspondence between driver module M and device node A is established, the driver modules corresponding to other device nodes that device node A depends on (such as the SPI bus controller device node represented by its parent node, and the interrupt controller node it references, etc.) are the dependent modules of driver module M. Thus, the hardware-level device node dependencies are successfully mapped to the driver module-level dependencies.

[0132] In some implementations, after determining the correspondence between each driver module and each device node, the method also includes:

[0133] Generate a table of correspondence between driver modules and device nodes. This table records the association between each driver module and its matching device nodes.

[0134] In one possible implementation, the driver module-device node mapping table refers to a data structure or data set used to record the matching associations between driver modules and device nodes. The driver module-device node mapping table contains multiple records, each indicating one or more device nodes matched by a driver module. For example, the driver module-device node mapping table can be presented in tabular form, with each row recording the node identification information of a driver module and its matched device nodes, or it can record the matching mapping relationship between driver modules and device nodes in key-value pair form.

[0135] In one possible implementation, generating a mapping table between driver modules and device nodes may include: obtaining the matching results between each driver module and each device node, whereby the matching results indicate the device nodes matched by each driver module and the driver modules matched by each device node; for each driver module, associating and recording the module identifier information of the driver module with the node identifier information of the matched device nodes; and generating a mapping relationship between driver modules and device nodes using the module identifier information of the driver module as an index and the node identifier information of the matched device nodes as the index content.

[0136] In this way, by generating a table of correspondence between driver modules and device nodes, the matching results between driver modules and device nodes are recorded in a structured manner, making the correspondence between driver modules and hardware devices clear and traceable. This provides a clear mapping basis for converting device node dependencies into driver module dependencies in the future, improving the accuracy and traceability of dependency conversion.

[0137] S104. Based on the correspondence between each driver module and each device node, and the dependency relationship between each device node, determine the driver module dependency table. The driver module dependency table is used to indicate the loading order between each driver module.

[0138] In one possible implementation, the driver module dependency table refers to a data structure or data set used to record the loading order dependencies between driver modules. The driver module dependency table contains multiple records, each indicating other driver modules that a driver module depends on, or directly indicating the loading order of the driver modules. For example, the driver module dependency table can be presented in tabular form, with each row recording the module identification information of a driver module and its dependent driver modules; or it can be presented in sequential list form, where the order of the driver modules in the list is the loading order, with the driver module listed earlier loading before the driver module listed later. The driver module dependency table is the final output of this application and can be used to guide the configuration of the driver module loading order during system startup, or to verify the correctness of existing loading order configurations.

[0139] In some implementations, determining the driver module dependency table may include:

[0140] Based on the driver module and device node correspondence table, the dependencies between device nodes in the device node dependency table are converted into dependencies between driver modules, generating a driver module dependency table.

[0141] In one possible implementation, based on the driver module-device node mapping table, the dependencies between device nodes in the device node dependency table are converted into dependencies between driver modules. This can include: traversing each record in the device node dependency table, and for each dependency between device nodes indicated in the record, finding the driver module corresponding to each device node in the dependency according to the driver module-device node mapping table; and converting the dependencies between device nodes into dependencies between the found driver modules.

[0142] In one possible implementation, generating the driver module dependency table may include: obtaining all the dependencies between driver modules converted from the device node dependency table; and generating the driver module dependency table using the module identifier information of each driver module as an index and the module identifier information of other driver modules that each driver module depends on as the index content.

[0143] In this way, by using the driver module to device node correspondence table, the hardware dependencies in the device node dependency table are converted into dependencies between driver modules, realizing automatic mapping from hardware topology to software loading order. This ensures that the final generated driver module dependency table can accurately reflect the physical constraints at the hardware level, solving the technical problem of incomplete dependency detection in dynamic detection schemes and providing a reliable order basis for the correct loading of driver modules when the system starts.

[0144] In this embodiment, the module identifier information of each driver module and the hardware matching identifiers supported by each driver module are obtained; a device tree file is obtained, each device node in the device tree file is parsed, the matching identifiers supported by each device node are extracted, and the dependencies between each device node are extracted; the hardware matching identifiers corresponding to each driver module are matched with the matching identifiers of each device node to determine the correspondence between each driver module and each device node; based on the correspondence between each driver module and each device node, and the dependencies between each device node, a driver module dependency table is determined, which is used to indicate the loading order between each driver module.

[0145] In the above method, the driver module and device tree file are jointly parsed through a static scanning mechanism. The matching relationship between the driver module and the hardware device can be automatically established during the coding stage without relying on the physical hardware environment. The dependency relationship between all nodes in the device tree can be completely extracted, covering all hardware dependencies, including implicit resource dependencies. This enables accurate detection of dependencies, thereby accurately generating the complete driver module loading order. This reduces the possibility of system startup failures caused by missed dependency detection and improves the iterative efficiency of driver development and the reliability of system startup.

[0146] Furthermore, the detection process can be executed during the compilation phase, meaning it can be triggered immediately after the driver module is compiled and the device tree file is generated, without waiting for the system image to be burned to the physical device or for the system to actually run. Performing the detection during the compilation phase allows dependency issues to be identified promptly during code writing and compilation, preventing problems from flowing into subsequent integration testing or real device verification stages. This shortens the defect discovery and repair cycle and reduces repair costs.

[0147] Based on the above embodiments, the driver module dependency table is also used for at least one of the following:

[0148] Verify whether the preset loading order of each driver module at system startup is consistent with the loading order indicated by the driver module dependency table. If they are inconsistent, output a prompt message; and / or, write to the system startup configuration file to instruct the system to load each driver module in sequence according to the loading order indicated by the driver module dependency table at system startup.

[0149] In one possible implementation, the preset loading order refers to the loading order of the driver modules currently configured in the system startup configuration file. This order is preset by the developers and may be subject to order conflicts due to human configuration errors or code changes.

[0150] In one possible implementation, the alert message refers to an alarm or notification message output to developers or operations personnel when the verification finds that the preset loading order is inconsistent with the loading order indicated by the driver module dependency table. This message may contain specific details of the conflict, such as which driver modules are in the wrong order and what the correct order should be.

[0151] In one possible implementation, the system startup configuration file can be obtained first, and the module identifier information and their arrangement order of each driver module recorded in the file can be read as the preset loading order. Then, the driver module dependency table generated in the aforementioned embodiment can be obtained, and the preset loading order can be compared with the loading order indicated by the driver module dependency table to determine whether the two are consistent. If the two are completely consistent, it means that the loading order of each driver module in the current system startup configuration file satisfies the physical dependency constraints at the hardware level, and no operation is required; if the two are inconsistent, a prompt message is output to remind the developer that there is an error in the loading order of the driver modules in the current system startup configuration file, and the developer can correct the system startup configuration file according to the driver module dependency table.

[0152] In one possible implementation, the driver module dependency table generated in the aforementioned embodiments can be obtained. Following the loading order indicated by the driver module dependency table, the module identification information of each driver module is sequentially written into the system startup configuration file to replace the original content in the system startup configuration file. During system startup, the kernel directly loads each driver module sequentially according to the order in the system startup configuration file, thereby ensuring that the loading order fully conforms to the physical dependency constraints at the hardware level.

[0153] In one possible implementation, the two methods described above can be combined. First, the verification process of implementation method one is executed. If the verification finds that the preset loading order is inconsistent with the loading order indicated by the driver module dependency table, a prompt message is output for developer confirmation. After receiving confirmation, the writing process of implementation method two is executed, writing the loading order indicated by the driver module dependency table into the system startup configuration file to automatically correct the loading order configuration. This combined approach retains the manual review step while achieving automatic configuration correction, improving both security and efficiency.

[0154] In this way, by using the driver module dependency table to verify the preset loading order or writing it into the system startup configuration file, the final result of dependency detection can be directly applied to the system startup process. The verification method can automatically detect loading order configuration errors before system startup and issue timely alerts, reducing the possibility of real-device startup failures due to configuration errors. The writing method can automatically correct the loading order configuration, ensuring that the system loads each driver module in the correct order during startup, without manual intervention. Using both methods in combination improves both the correctness of the configuration and the automation level of driver development and system configuration.

[0155] Figure 2 A schematic diagram of the kernel module dependency detection device based on static scanning provided in this application is shown below. Figure 2 As shown, the kernel module dependency detection device 200 based on static scanning provided in this embodiment includes: an acquisition module 201, a first processing module 202, a second processing module 203, and a determination module 204, wherein,

[0156] The acquisition module 201 is used to acquire the module identification information of each driver module and the hardware matching identifiers supported by each driver module.

[0157] The first processing module 202 is used to obtain a device tree file, parse each device node in the device tree file, extract the matching identifiers supported by each device node, and extract the dependency relationships between each device node.

[0158] The second processing module 203 is used to match the hardware matching identifiers corresponding to each driver module with the matching identifiers of each device node to determine the correspondence between each driver module and each device node.

[0159] The determination module 204 is used to determine the driver module dependency table based on the correspondence between each driver module and each device node, as well as the dependency relationship between each device node. The driver module dependency table is used to indicate the loading order between each driver module.

[0160] The kernel module dependency detection device based on static scanning provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0161] In one possible implementation, the acquisition module 201 is specifically used for:

[0162] Obtain the system startup configuration file, which includes module identification information for all driver modules that need to be loaded;

[0163] Extract the module identification information of each driver module from the system startup configuration file.

[0164] In one possible implementation, the acquisition module 201 is specifically used for:

[0165] Obtain the compilation metadata files of each driver module and determine the source code file path information based on the compilation metadata files. The compilation metadata files are used to indicate the source code file path information corresponding to each driver module.

[0166] Based on the source code file path information, obtain the source code files corresponding to each driver module;

[0167] Extract the hardware matching identifiers supported by each driver module from the source code files corresponding to each driver module.

[0168] In one possible implementation, the first processing module 202 is specifically used for:

[0169] Extract the parent-child dependencies between device nodes. These dependencies indicate the hierarchical dependencies between parent and child device nodes in the device tree; and / or,

[0170] Extract the reference dependencies between device nodes. The reference dependencies are used to indicate the resource reference relationship between one device node and another device node.

[0171] In one possible implementation, the first processing module 202 is specifically used for:

[0172] If a device node references another device node that itself references other device nodes, recursively resolve all levels of reference relationships until there are no further references.

[0173] In one possible implementation, the kernel module dependency detection device 200 based on static scanning further includes a third processing module 205, which is used for:

[0174] Based on the dependencies between each device node, a device node dependency table is determined. The device node dependency table is used to indicate the dependencies between each device node.

[0175] In one possible implementation, the third processing module 205 is specifically used for:

[0176] Generate a driver module to device node mapping table. This table records the association between each driver module and its matching device nodes.

[0177] Determine the driver module dependency table, including:

[0178] Based on the driver module and device node correspondence table, the dependencies between device nodes in the device node dependency table are converted into dependencies between driver modules, generating a driver module dependency table.

[0179] In one possible implementation, the driver module dependency table is also used for at least one of the following:

[0180] Verify whether the preset loading order of each driver module at system startup is consistent with the loading order indicated by the driver module dependency table. If they are inconsistent, output a prompt message; and / or,

[0181] Write to the system startup configuration file to instruct the system to load each driver module in the order indicated by the driver module dependency table during system startup.

[0182] The kernel module dependency detection device based on static scanning provided in this application embodiment can execute the technical solution shown in the above method embodiment. Its implementation principle and beneficial effects are similar, and will not be described again here.

[0183] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 3 As shown, the electronic device 300 may include: a transceiver 301, a processor 302, and a memory 303.

[0184] Processor 302 executes computer execution instructions stored in memory, causing processor 302 to perform the scheme in the above embodiments. Processor 302 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0185] The memory 303 is connected to the processor 302 via the system bus and completes communication between them. The memory 303 is used to store computer program instructions.

[0186] Transceiver 301 can be used to obtain the task to be run and its configuration information.

[0187] The system bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the diagram, but this does not indicate that there is only one bus or one type of bus. Transceivers are used to enable communication between database access devices and other computers (e.g., clients, read-write libraries, and read-only libraries). Memory may include random access memory (RAM) and may also include non-volatile memory.

[0188] It should be noted that the electronic devices provided in this application are devices with computing capabilities, including but not limited to servers and computers.

[0189] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0190] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0191] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0192] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0193] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0194] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0195] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0196] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the tasks of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0197] Those skilled in the art will understand that all or part of the tasks described in the above method embodiments can be implemented by hardware associated with program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the tasks described in the above method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0198] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A kernel module dependency detection method based on static scanning, characterized in that, include: Obtain the module identification information of each driver module, as well as the hardware matching identifiers supported by each driver module; Obtain the device tree file, parse each device node in the device tree file, extract the matching identifiers supported by each device node, and extract the dependencies between each device node; The hardware matching identifiers corresponding to each driver module are matched with the matching identifiers of each device node to determine the correspondence between each driver module and each device node; Based on the correspondence between each driver module and each device node, and the dependency relationship between each device node, a driver module dependency table is determined. The driver module dependency table is used to indicate the loading order between each driver module.

2. The method according to claim 1, characterized in that, Obtain the module identification information of each driver module, including: Obtain the system startup configuration file, which includes module identification information for all driver modules that need to be loaded; Extract the module identification information of each driver module from the system startup configuration file.

3. The method according to claim 1, characterized in that, Obtain the hardware matching identifiers supported by each driver module, including: Obtain the compilation metadata files of each driver module and determine the source code file path information based on the compilation metadata files. The compilation metadata files are used to indicate the source code file path information corresponding to each driver module. Based on the source code file path information, obtain the source code file corresponding to each driver module; Extract the hardware matching identifiers supported by each driver module from the source code files corresponding to each driver module.

4. The method according to claim 1, characterized in that, Extracting the dependencies between the device nodes includes: Extract the parent-child dependencies between each device node, whereby the parent-child dependencies indicate the hierarchical dependencies between parent and child device nodes in the device tree; and / or, Extract the reference dependencies between each device node, which are used to indicate the resource reference relationship between one device node and another device node.

5. The method according to claim 4, characterized in that, Extracting the reference dependencies between the device nodes includes: If a device node references another device node that itself references other device nodes, recursively resolve all levels of reference relationships until there are no further references.

6. The method according to claim 1, characterized in that, After extracting the dependencies between the device nodes, the method further includes: Based on the dependencies between the device nodes, a device node dependency table is determined, which is used to indicate the dependencies between the device nodes.

7. The method according to claim 6, characterized in that, The method further includes: Generate a driver module and device node correspondence table, which is used to record the association between each driver module and each matching device node; Determining the driver module dependency table includes: Based on the driver module and device node correspondence table, the dependencies between device nodes in the device node dependency table are converted into dependencies between driver modules, thereby generating the driver module dependency table.

8. The method according to claim 1, characterized in that, The driver module dependency table is also used for at least one of the following: Verify whether the preset loading order of each driver module at system startup is consistent with the loading order indicated by the driver module dependency table. If they are inconsistent, output a prompt message; and / or, Write to the system startup configuration file to instruct the system to load each driver module sequentially according to the loading order indicated by the driver module dependency table when the system starts.

9. A kernel module dependency detection device based on static scanning, characterized in that, include: The module comprises an acquisition module, a first processing module, a second processing module, and a determination module, wherein, The acquisition module is used to acquire the module identification information of each driver module and the hardware matching identifiers supported by each driver module. The first processing module is used to obtain a device tree file, parse each device node in the device tree file, extract the matching identifiers supported by each device node, and extract the dependency relationships between each device node. The second processing module is used to match the hardware matching identifiers corresponding to each driver module with the matching identifiers of each device node to determine the correspondence between each driver module and each device node; The determining module is used to determine a driver module dependency table based on the correspondence between each driver module and each device node, and the dependency relationship between each device node. The driver module dependency table is used to indicate the loading order between each driver module.

10. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 8.

Images