Kernel module construction method and device, electronic device, and storage medium

Abstract

The present disclosure provides a kernel module construction method and device, electronic equipment and storage medium, and relates to the technical field of computer development. The method comprises: obtaining kernel source code information and construction environment information corresponding to a target kernel module to be constructed, and generating kernel construction intermediate data conforming to kernel module construction specifications and performing a compilation operation according to the source code list and dependencies in the kernel source code information; meanwhile, the compilation context information is associated with an index target associated with the source code list during the construction process, the compilation metadata used for code indexing is generated, and the compilation metadata is synchronously exported during the execution of the compilation operation. The present scheme can establish a corresponding relationship between the compilation context information involved in the construction process and the source code and uniformly express the relationship, thereby improving the consistency and controllability of the construction process and enhancing the accuracy of code analysis and parsing in the development process.

Description

Technical Field

[0001] This disclosure relates to the field of computer development technology, and more specifically, to a method and apparatus for constructing a kernel module, an electronic device, and a storage medium. Background Technology

[0002] Currently, the construction of Linux kernel modules (Loadable Kernel Modules, LKMs) typically relies on dedicated build systems that match the kernel environment, such as the Kbuild system. These dedicated build systems can compile and link kernel modules according to kernel configuration, source code composition, and build rules, and generate loadable kernel module object files.

[0003] However, dedicated build systems for related technologies cannot automatically export compilation metadata containing complex kernel macro definitions and header file paths. Mainstream integrated development environments (IDEs) typically rely on compilation databases to provide code completion, definition navigation, and static analysis functions. Dedicated build systems cannot generate such databases, causing developers to face a large number of false syntax error prompts when writing kernel modules, rendering code navigation functions ineffective, and severely reducing development efficiency and code maintainability.

[0004] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The purpose of this disclosure is to provide a method, apparatus, electronic device, and storage medium for constructing a kernel module, thereby improving the consistency and controllability of the construction process and enhancing the accuracy of code parsing and analysis during development.

[0006] According to a first aspect of the present disclosure, a method for constructing a kernel module is provided, comprising: obtaining kernel source code information and build environment information corresponding to a target kernel module to be constructed, wherein the kernel source code information includes a source code list of the target kernel module and dependencies between the target kernel module and its dependent objects, and the build environment information includes a kernel build path of the target kernel module and compilation context information; generating kernel build intermediate data conforming to the kernel module construction specification based on the source code list and dependencies; associating the compilation context information with an index target associated with the source code list to generate compilation metadata for code indexing; invoking a kernel module construction system to perform a compilation operation for the target kernel module based on the kernel build intermediate data and the kernel build path to construct the target kernel module; and synchronously exporting compilation metadata based on the index target during the execution of the compilation operation for code parsing and indexing by an integrated development environment.

[0007] In some example embodiments of this disclosure, based on the foregoing scheme, the kernel build intermediate data includes intermediate build files; generating kernel build intermediate data conforming to the kernel module build specification according to the source code list and dependencies includes: determining the module composition relationship corresponding to the target kernel module according to the source code list and dependencies, the module composition relationship being used to characterize the correspondence between the target kernel module and the source files involved in compilation; writing the module composition relationship into the intermediate build file according to the syntax form recognizable by the kernel module build system to obtain kernel build intermediate data conforming to the kernel module build specification.

[0008] In some example embodiments of this disclosure, based on the foregoing scheme, the module composition relationship corresponding to the target kernel module is determined according to the source code list and dependencies, including: generating module target definition information based on the source code list; generating target file mapping relationships based on each source file in the source code list; generating dependency target declaration information based on dependencies; and determining the module composition relationship corresponding to the target kernel module based on the module target definition information, target file mapping relationships, and dependency target declaration information.

[0009] In some example embodiments of this disclosure, based on the foregoing scheme, before invoking the kernel module build system to perform compilation operations for the target kernel module based on kernel build intermediate data and kernel build path, the method further includes: constructing an entity build target for performing compilation operations based on the source code list and dependencies; associating the kernel build intermediate data with the entity build target, so as to trigger the kernel module build system to perform compilation operations through the entity build target.

[0010] In some example embodiments of this disclosure, based on the foregoing scheme, the index target includes a virtual index target; before associating compilation context information with the index target associated with the source code list and generating compilation metadata for code indexing, the method further includes: creating a build target of an object type and setting the build target of the object type to not participate in the default build process; associating the source code list with the build target of the object type to obtain a virtual index target.

[0011] In some example embodiments of this disclosure, based on the foregoing scheme, the compilation context information includes the kernel header file path and kernel compilation macro definition parameters; associating the compilation context information with the index target associated with the source code list to generate compilation metadata for code indexing includes: setting the kernel header file path as the header file search path of the index target; adding the kernel compilation macro definition parameters and preset kernel identifier macros to the compilation parameters of the index target; and generating compilation metadata for code indexing based on the header file search path and compilation parameters.

[0012] In some example embodiments of this disclosure, based on the foregoing scheme, based on kernel build intermediate data and kernel build path, the kernel module build system is invoked to perform a compilation operation for the target kernel module to build the target kernel module, including: in response to the compilation instruction for invoking the kernel module build system, the kernel module build system is triggered to read the kernel build intermediate data and perform a compilation operation for the target kernel module; wherein, the compilation instruction carries the kernel build path and the intermediate build file path corresponding to the kernel build intermediate data.

[0013] In some example embodiments of this disclosure, based on the foregoing scheme, a compilation operation is performed on the target kernel module to construct the target kernel module, including: compiling each source file in the source code list based on kernel construction intermediate data to generate intermediate target files; performing linking processing based on the intermediate target files to generate kernel module target files corresponding to the target kernel module; and constructing the target kernel module based on the kernel module target files.

[0014] In some example embodiments of this disclosure, based on the aforementioned scheme, the compilation metadata includes a structured compilation metadata file; during the compilation operation, the compilation metadata is synchronously exported based on the index target, including: during the compilation operation, recording the compilation commands and compilation parameters corresponding to the index target; constructing a compilation database structure based on the compilation commands and compilation parameters; generating and exporting a structured compilation metadata file based on the compilation database structure; wherein, the structured compilation metadata file is used to provide the header file path, macro definition parameters, and compilation options corresponding to the source file to support code parsing, jumping, and auto-completion functions.

[0015] In some example embodiments of this disclosure, based on the foregoing scheme, obtaining the build environment information corresponding to the target kernel module to be built includes: obtaining the processor architecture information of the runtime environment corresponding to the target kernel module; determining the build architecture parameters of the target kernel module based on the processor architecture information; searching for the kernel build path according to a preset search path or a user-specified path based on the build architecture parameters; and parsing the configuration files in the kernel build path to extract the compilation context information.

[0016] In some example embodiments of this disclosure, based on the foregoing scheme, the compilation context information includes the kernel header file path and kernel compilation macro definition parameters, and the configuration file includes an automatic configuration file; parsing the configuration file in the kernel build path and extracting the compilation context information includes: parsing the automatic configuration file in the kernel build path to obtain configuration macros related to the target kernel module; converting the configuration macros into a set of macro definition parameters that the kernel module build system can recognize to obtain kernel compilation macro definition parameters; and determining the kernel header file path based on the kernel build path.

[0017] In some example embodiments of this disclosure, based on the foregoing scheme, obtaining the kernel source code information corresponding to the target kernel module to be built includes: receiving module definition instructions for the target kernel module; parsing the module definition instructions to obtain a source code list and the dependencies between the target kernel module and its dependent objects.

[0018] According to a second aspect of the present disclosure, a kernel module building apparatus is provided, comprising: a kernel environment detection module, configured to acquire kernel source code information and build environment information corresponding to a target kernel module to be built, wherein the kernel source code information includes a source code list of the target kernel module and dependencies between the target kernel module and its dependent objects, and the build environment information includes the kernel build path of the target kernel module and compilation context information; an intermediate file generation module, configured to generate kernel build intermediate data conforming to the kernel module building specification based on the source code list and dependencies; an index metadata generation module, configured to associate the compilation context information with an index target associated with the source code list and generate compilation metadata for code indexing; a compilation execution module, configured to call a kernel module building system to perform compilation operations for the target kernel module based on the kernel build intermediate data and the kernel build path, and build the target kernel module; and a metadata export module, configured to synchronously export compilation metadata based on the index target during the execution of the compilation operation, for use by an integrated development environment for code parsing and indexing.

[0019] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a processor; and a memory storing computer-readable instructions that, when executed by the processor, implement the method for constructing a kernel module in the first aspect.

[0020] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided, on which a computer program is stored, wherein when executed by a processor, the computer program implements the method for constructing the kernel module in the first aspect.

[0021] The technical solutions provided in this disclosure can include the following beneficial effects: The kernel module construction method in the example embodiments of this disclosure, on the one hand, pre-acquires the kernel source code information and build environment information corresponding to the target kernel module to be built during the kernel module construction process, and uniformly organizes the source code list, the dependencies between the target kernel module and its dependent objects, the kernel build path, and the compilation context information. This allows the compilation context information, which was originally dynamically inferred internally by the build system, to participate in the processing in an explicit form during the build process. Furthermore, it combines the source code list and dependencies to generate kernel build intermediate data that conforms to the kernel module construction specification, thereby establishing a stable correspondence between the compilation behavior and its dependency information, reducing the uncertainty caused by implicit dependencies, and improving the consistency and controllability of the build process. On the other hand, by generating kernel build intermediate data that conforms to the kernel module construction specification based on the source code list and dependencies, and calling the kernel module construction system accordingly, the method further... The system performs compilation operations on the target kernel module to build it, enabling the module target definition, source file mapping relationship, and dependency structure to be expressed and scheduled in a regular manner. This maintains the clarity and traceability of the build logic in multi-file and multi-dependency scenarios, reduces the impact of build script complexity on the development process, and improves the standardization and maintenance efficiency of the build process. On the other hand, by associating compilation context information with the index target associated with the source code list during the build process, compilation metadata for code indexing is generated. During compilation execution, compilation metadata is synchronously exported based on the index target, enabling the compilation key information scattered within the build system to form a unified expression. This provides a foundation for the development environment to obtain complete and consistent compilation context information, improves the consistency and completeness of context information during code parsing, and enhances code understanding and analysis accuracy during the development process.

[0022] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0024] Figure 1 The diagram illustrates a method for constructing a kernel module according to some embodiments of the present disclosure.

[0025] Figure 2 The illustration shows a flowchart of obtaining build environment information corresponding to a target kernel module according to some embodiments of the present disclosure.

[0026] Figure 3 The illustration shows a schematic diagram of the process for generating intermediate build files according to some embodiments of the present disclosure.

[0027] Figure 4 The illustration schematically depicts a process diagram for constructing a virtual index target according to some embodiments of the present disclosure.

[0028] Figure 5 The illustration shows a schematic diagram of the process of building kernel modules and generating code indexes based on CMake according to some embodiments of the present disclosure.

[0029] Figure 6 The illustration shows a timing flow diagram of kernel module building and compilation metadata generation based on CMake according to some embodiments of the present disclosure.

[0030] Figure 7 The illustration shows a schematic diagram of a construction apparatus for a kernel module according to some embodiments of the present disclosure.

[0031] Figure 8 The schematic diagram illustrates the structural schematic of a computer system of an electronic device according to some embodiments of the present disclosure.

[0032] Figure 9 A schematic diagram of a computer-readable storage medium according to some embodiments of the present disclosure is shown.

[0033] In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts. Detailed Implementation

[0034] 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 numerals 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 specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this specification as detailed in the appended claims.

[0035] Furthermore, the accompanying drawings are for illustrative purposes only and are not necessarily drawn to scale. The block diagrams shown in the drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0036] In this example embodiment, a method for building a kernel module is first provided, which can be applied to terminal devices. Figure 1 The illustration schematically shows a flowchart of a method for constructing a kernel module according to some embodiments of the present disclosure. Reference Figure 1 As shown, the method for building this kernel module may include the following steps: Step S110: Obtain the kernel source code information and build environment information corresponding to the target kernel module to be built. The kernel source code information includes the source code list of the target kernel module and the dependencies between the target kernel module and its dependent objects. The build environment information includes the kernel build path of the target kernel module and the compilation context information. Step S120: Generate intermediate kernel build data that conforms to the kernel module build specification based on the source code list and dependencies; Step S130: Associate the compilation context information with the index target associated with the source code list to generate compilation metadata for code indexing; Step S140: Based on the kernel build intermediate data and kernel build path, call the kernel module build system to perform the compilation operation for the target kernel module and build the target kernel module; In step S150, during the compilation operation, compilation metadata is synchronously exported based on the index target for code parsing and indexing by the integrated development environment.

[0037] According to the kernel module construction method in this example embodiment, on the one hand, by pre-acquiring the kernel source code information and build environment information corresponding to the target kernel module to be built during the kernel module construction process, and uniformly organizing the source code list, the dependencies between the target kernel module and its dependent objects, the kernel build path, and the compilation context information, the compilation context information that was originally dynamically inferred internally by the build system can participate in the processing in an explicit form during the build process. Furthermore, by combining the source code list and dependencies to generate kernel build intermediate data that conforms to the kernel module construction specification, a stable correspondence is established between the compilation behavior and its dependency information, reducing the uncertainty caused by implicit dependencies and improving the consistency and controllability of the build process. On the other hand, by generating kernel build intermediate data that conforms to the kernel module construction specification based on the source code list and dependencies, and calling the kernel module construction system accordingly, the kernel module construction system is executed. The system performs compilation operations on the target kernel module to build it, enabling the module target definition, source file mapping relationship, and dependency structure to be expressed and scheduled in a regular manner. This maintains the clarity and traceability of the build logic in multi-file and multi-dependency scenarios, reduces the impact of build script complexity on the development process, and improves the standardization and maintenance efficiency of the build process. On the other hand, by associating compilation context information with the index target associated with the source code list during the build process, compilation metadata for code indexing is generated. During compilation execution, compilation metadata is synchronously exported based on the index target, enabling the compilation key information scattered within the build system to form a unified expression. This provides a foundation for the development environment to obtain complete and consistent compilation context information, improves the consistency and completeness of context information during code parsing, and enhances code understanding and analysis accuracy during the development process.

[0038] The construction method of the kernel module in this example embodiment will be further explained below.

[0039] In step S110, the kernel source code information and build environment information corresponding to the target kernel module to be built are obtained. The kernel source code information includes the source code list of the target kernel module and the dependencies between the target kernel module and its dependent objects. The build environment information includes the kernel build path of the target kernel module and the compilation context information.

[0040] In one example embodiment of this disclosure, a target kernel module refers to a module program that needs to be compiled in a Linux kernel environment to generate kernel module object files. For example, it may be a device driver module, a protocol extension module, or a kernel feature enhancement module. Linux kernel modules rely on a complete kernel build environment during compilation; therefore, build environment information describes the kernel context on which the target kernel module depends, and kernel source code information describes the source code components involved in the construction of the target kernel module and the dependencies between the target kernel module and its dependent objects.

[0041] The kernel build path indicates the source code directory or build directory where the kernel build system is located. For example, it can be the system's default kernel build directory or the kernel directory specified by the user through parameters. The compilation context information can include the kernel header file path and kernel compilation macro definition parameters. The kernel header file path indicates the set of paths where kernel interface definitions, architecture-related definitions, and automatically generated header files are located. The kernel compilation macro definition parameters are used to characterize kernel configuration macros, module compilation identifier macros, and architecture-related conditional compilation parameters. For example, it can include configuration macros, module identifier macros, and a set of macros that match the architecture. This embodiment does not limit the specific content of the above kernel source code information and build environment information.

[0042] The aforementioned build environment information can be automatically obtained through a build environment detection mechanism. For example, the processor architecture information of the current system can be detected to determine the build architecture parameters corresponding to the target kernel module. Subsequently, the kernel build path can be searched based on a preset search path or a user-specified path, such as locating the kernel build directory in the system's default module directory or the user-configured path. After determining the kernel build path, the configuration files in that path can be parsed or automatically generated, kernel configuration macros can be extracted from them, and the kernel configuration macros can be converted into macro definition parameter forms that the compiler can recognize. At the same time, the corresponding header file directory can be extracted from the kernel build path as the kernel header file path.

[0043] Kernel source code information can be obtained through the encapsulated module definition interface. For example, developers can call the interface for defining kernel modules in the build script, passing in a set of source files and dependency information as parameters. After receiving the module definition instruction for the target kernel module, the system can parse the instruction to obtain the source code list and the dependencies between the target kernel module and its dependent objects. The source code list may include the main driver file, function implementation files, and auxiliary tool files; dependencies may include common components or other modules that the target kernel module depends on.

[0044] In step S120, intermediate kernel build data conforming to the kernel module build specification is generated based on the source code list and dependencies.

[0045] In one example embodiment of this disclosure, kernel build intermediate data refers to data generated based on the source code list and dependencies of the target kernel module, which can be recognized by the kernel module build system and used to perform compilation operations. Kernel build intermediate data may include intermediate build files, which are description files conforming to the kernel module build system specification, used to describe the correspondence between the target kernel module and the source files involved in the compilation.

[0046] First, the module composition relationship corresponding to the target kernel module can be determined based on the source code list and dependencies. The module composition relationship is used to characterize the correspondence between the target kernel module and the source files involved in compilation. For example, module target definition information can be generated based on the source code list, target file mapping relationships can be generated based on each source file in the source code list, and dependency target declaration information can be generated based on dependencies. Subsequently, the module composition relationship corresponding to the target kernel module can be determined based on the module target definition information, target file mapping relationships, and dependency target declaration information.

[0047] After determining the module composition relationships, these relationships can be written into intermediate build files according to the syntax recognizable by the kernel module build system, resulting in kernel build intermediate data that conforms to the kernel module build specifications. This intermediate build file can be automatically generated without requiring manual writing by developers, thus reducing build script maintenance costs. Furthermore, by converting the source code list and dependencies into kernel build intermediate data conforming to the kernel module build specifications, the source code composition and dependency structure of the target kernel module can participate in the build process in a rule-based manner, improving the standardization and traceability of the build process.

[0048] As an alternative implementation, before invoking the kernel module build system based on kernel build intermediate data and kernel build path to execute the compilation operation for the target kernel module, an entity build target for performing the compilation operation can be built based on the source code list and dependencies. The kernel build intermediate data can be associated with the entity build target, thereby triggering the kernel module build system to execute the compilation operation through the entity build target. The entity build target can depend on the source code list and intermediate build files, and execute the compilation operation by invoking the kernel module build system. The entity build target can be implemented using custom build commands and can form dependencies with other targets in the build system.

[0049] In step S130, the compilation context information is associated with the index target associated with the source code list to generate compilation metadata for code indexing.

[0050] In one example embodiment of this disclosure, an index target refers to a build target created during the build process to carry compilation context information. It can be associated with the source code list of the target kernel module so that the compilation context information can be attached to the corresponding source code. An index target may include a virtual index target, which can be a build target that does not participate in the actual compilation output generation. Essentially, it is a logical build unit associated with the source code list of the target kernel module. This virtual index target can be understood as a virtual path in the target kernel module build process, primarily used to describe the context information required by the source files during compilation, rather than for generating kernel module target files.

[0051] Compilation metadata refers to a structured collection of information that can characterize the compilation behavior of source files. It can include header file search paths, macro definition parameters, and compilation options, and is used to support the Integrated Development Environment (IDE) in parsing, jumping, and semantic analysis of code.

[0052] A build target of type object can be created based on a list of source files, and this build target can be set not to participate in the default build process. For example, this index target can be created using the object library mechanism in the build system, establishing an association between it and each source file in the source file list. This allows the build system to generate corresponding compilation parameter records for this index target when generating compilation commands. Setting the index target not to participate in the default build process can prevent it from affecting the actual compilation output of the target kernel module.

[0053] The kernel header file path can be set as the header file search path of the index target, enabling the source code to access kernel interface definitions and architecture-related declarations during parsing. At the same time, kernel compiler macro definition parameters can be added to the compilation parameters of the index target, such as injecting kernel configuration macros, module identifier macros, and preset kernel identifier macros in a unified manner, so that the source file can correctly identify conditional compilation branches during parsing.

[0054] Module compilation identifier macros can be injected into the index target to simulate the compilation state of the target kernel module in a real build environment, thus making the generated compilation metadata closer to real compilation behavior. Alternatively, the index target can automatically output the corresponding set of compilation parameters during the generation process through the build system's compilation command export mechanism. This embodiment does not limit the specific implementation form of the index target, as long as it can carry the source code list and its compilation context information. By associating the compilation context information with the index target associated with the source code list, compilation metadata for code indexing can be generated. This allows the compilation context information, originally encapsulated within the kernel module build system, to be explicitly attached to the source code list, enabling compilation parameters to be organized in a unified structure and improving context consistency during code parsing.

[0055] In step S140, based on the kernel build intermediate data and kernel build path, the kernel module build system is invoked to perform the compilation operation for the target kernel module and build the target kernel module.

[0056] In one example embodiment of this disclosure, the kernel module build system refers to a build system provided in the kernel source tree for compiling external modules, which can complete module compilation and linking based on module description files and kernel configuration. Kernel build intermediate data, as one of the inputs to this build system, describes the composition structure and source file mapping relationships of the target kernel module. The kernel module object file refers to the module file generated through compilation and linking that can be loaded and executed by the kernel.

[0057] It is possible to construct compilation instructions that invoke the kernel module build system. These instructions can carry the kernel build path and the paths to intermediate build files corresponding to the kernel build intermediate data. For example, the kernel build path can be specified through a build command, and the directory containing the intermediate build files can be passed as the module build directory to the kernel module build system, thereby triggering it to read the kernel build intermediate data and execute the compilation operation for the target kernel module. During execution, the kernel module build system can compile each source file in the source code list according to the module target definition information and target file mapping relationship in the intermediate build file. After the target files are generated, it performs linking processing, ultimately generating the kernel module target file corresponding to the target kernel module, and completing the construction of the target kernel module based on the kernel module target file.

[0058] Optionally, the above compilation instructions can be encapsulated into a build target within the build system through custom build commands, making it dependent on the source code list, intermediate build files, and dependencies. When the above inputs change, recompilation can be automatically triggered, thus maintaining consistency between the build result and the source file state. By calling the kernel module build system to perform compilation operations based on kernel build intermediate data and the kernel build path, automated construction of the target kernel module can be achieved without changing the original mechanism of the kernel module build system. The kernel build intermediate data serves as a bridge connecting the source code list, dependencies, and underlying compilation execution, thereby improving the standardization and consistency of the build process.

[0059] In step S150, during the compilation operation, compilation metadata is synchronously exported based on the index target for code parsing and indexing by the integrated development environment.

[0060] In one example embodiment of this disclosure, compilation metadata can be used to describe a structured data set of source file compilation context, which may include information such as compilation commands, compilation parameters, header file search paths, macro definition parameters, and working directories. Integrated development environments typically rely on this type of compilation metadata to obtain the actual compilation context of the source file when performing code parsing, semantic analysis, and auto-completion.

[0061] The compilation commands and parameters corresponding to the indexed target can be recorded during the compilation process. For example, when the build system generates a compilation call, the list of source code associated with the indexed target and its compilation parameters can be recorded together. Subsequently, a compilation database structure can be built based on the compilation commands and parameters, and a structured compilation metadata file can be generated, for example, using JavaScript Object Notation (JSON) format to organize the data. For each source file in the source code list, a corresponding record can be generated in the structured compilation metadata file, which can include the source file path, compilation command, header file path, and macro definition parameters.

[0062] The compilation metadata can be automatically generated during the build process by enabling the build system's compilation command export mechanism; alternatively, a custom script can be used to intercept the compilation commands and extract parameters to generate a structured compilation metadata file. This embodiment does not limit the method of generating the compilation metadata file.

[0063] By synchronously exporting compilation metadata during the compilation process, the compilation process of the target kernel module can be kept consistent with the generation process of the compilation context data. This avoids information discrepancies between the compilation behavior and the code parsing environment, enabling the integrated development environment to perform code parsing based on the real compilation context, thereby improving the accuracy of code jumps, auto-completion, and semantic analysis.

[0064] The contents of steps S110 to S150 will be described in detail below.

[0065] In one example embodiment of this disclosure, it can be achieved through Figure 2 The steps in the document to obtain the build environment information corresponding to the target kernel module are as follows: Figure 2 As shown, it can specifically include: Step S210: Obtain the processor architecture information of the runtime environment corresponding to the target kernel module; Step S220: Determine the construction architecture parameters of the target kernel module based on the processor architecture information; Step S230: Based on the architecture parameters, search for the kernel build path according to the preset search path or the user-specified path; Step S240: Parse the configuration files in the kernel build path and extract the compilation context information.

[0066] The processor architecture information refers to the identifier information used to characterize the central processing unit architecture type adopted by the runtime environment corresponding to the target kernel module. For example, it may include x86 architecture, x86_64 architecture, ARM architecture, ARM64 architecture, etc., but this embodiment is not limited to these. Since the compilation process of the Linux kernel module depends on the instruction set and compilation rules of the target architecture, the kernel configuration, header file organization, and compilation options differ for different processor architectures. Therefore, determining the processor architecture information first during the acquisition of build environment information is beneficial for determining the subsequent build architecture parameters.

[0067] Processor architecture information can be obtained by reading system environment variables, calling system interfaces, or parsing system identifier variables provided by the build tool. For example, the current system processor type can be obtained through variables in the build system, or the architecture identifier string can be obtained by executing system commands. In cross-compilation scenarios, target processor architecture information can also be obtained through user-specified target platform parameters. This embodiment does not impose any special limitations on the method of obtaining processor architecture information.

[0068] Optionally, the acquired processor architecture information can be standardized, for example, by mapping architecture identifiers from different sources to a unified internal representation for subsequent processing. By obtaining the processor architecture information of the runtime environment corresponding to the target kernel module, the construction process of the target kernel module can be kept consistent with the target architecture, which helps reduce compilation errors caused by architecture mismatch.

[0069] Build architecture parameters refer to the set of architecture-related parameters used to guide the kernel module build system in compilation. For example, build architecture parameters may include architecture identifier parameters, cross-compilation toolchain parameters, and compilation options related to the target architecture. The process of determining build architecture parameters essentially involves converting processor architecture information into specific parameter forms that the kernel module build system can recognize and use, thereby enabling the compilation process to correctly adapt to the target architecture.

[0070] In practical implementation, the corresponding architecture identifier parameters can be determined based on the processor architecture information. For example, the processor architecture information can be mapped to architecture identifier variables in the build system. In cross-compilation scenarios, the cross-compilation toolchain prefix and toolchain path can be further determined based on the processor architecture information, thus forming a complete set of build architecture parameters. In addition, corresponding kernel configuration options or compilation options can be selected based on the processor architecture information, enabling the generated kernel module object files to run correctly on the target platform.

[0071] Automatic conversion from processor architecture information to build architecture parameters can be achieved through a preset architecture mapping table, such as establishing a mapping relationship between different architectures and their corresponding parameters. Alternatively, parameters related to the current architecture can be obtained by parsing configuration files in the kernel build path. This embodiment does not limit the specific composition of the build architecture parameters, as long as they can guide the kernel module build system to complete the compilation under the target architecture. By determining the build architecture parameters based on processor architecture information, the build process can automatically adapt to different architecture environments, thereby avoiding the complexity of manually configuring architecture parameters and improving the automation and accuracy of the build process.

[0072] The kernel build path refers to the kernel source code directory or build output directory used to perform kernel module build operations. It typically contains kernel configuration files, build scripts, and the header file structure required for compilation. Since the kernel build path may differ across different system environments or development scenarios, it is necessary to search and locate it among multiple candidate paths based on build architecture parameters.

[0073] The system can search for kernel build paths that match the current build architecture parameters from a set of preset search paths. For example, it can search for the build directory of the corresponding version in the system's default kernel module directory. Alternatively, it can directly specify the kernel build path based on the path parameters entered by the user. During the search process, the system can verify whether the path contains key files or directories required by the kernel build system, such as configuration files or build directories, to determine if the path is a valid kernel build path.

[0074] In one optional implementation, the user-specified path can be used as the first choice for search results. If the user does not specify a path, the search will then proceed sequentially through preset search paths. Alternatively, kernel version information can be used to further filter matching paths. This embodiment does not limit the search strategy for kernel build paths. By searching for kernel build paths based on build architecture parameters, the build process can automatically locate the kernel build environment that matches the target architecture, thereby reducing the complexity of manual path configuration and improving the accuracy of build environment matching.

[0075] A configuration file is a file located in the kernel build path that describes the kernel compilation configuration. It can be an automatically generated configuration file or another file containing kernel configuration macros. Compilation context information can include kernel header file paths and kernel compilation macro definition parameters. Kernel compilation macro definition parameters are a set of macro definitions used to control conditional compilation and feature switches during the compilation process. Kernel header file paths are a set of directory paths containing kernel interface definitions and architecture-related definitions.

[0076] The system can read configuration files from the kernel build path, parse the configuration macros within them, and extract kernel compilation macro definition parameters related to the target kernel module. For example, it can extract kernel configuration macros from the configuration files and convert them into macro definition parameter forms that the compiler can recognize. Simultaneously, it can determine the kernel header file paths based on the directory structure in the kernel build path, such as obtaining general header file directories, architecture-related header file directories, and automatically generated header file directories. Optionally, the extracted macro definition parameters can be filtered during the parsing process, retaining only macros related to the target kernel module; alternatively, kernel header file paths can be categorized, for example, distinguishing between common header file paths and architecture-related header file paths.

[0077] By obtaining the processor architecture information of the runtime environment corresponding to the target kernel module, and determining the build architecture parameters of the target kernel module based on this, and locating the kernel build path by combining the preset search path or the user-specified path, and further parsing the configuration files in the kernel build path to obtain the compilation context information, the build process of the target kernel module can be carried out in a kernel environment consistent with the target architecture. This transforms the acquisition of build environment information from relying on manual configuration to an automatic adaptation process based on the runtime environment, thereby improving the accuracy and consistency of build environment matching and reducing the risk of build anomalies caused by inconsistent architecture configuration.

[0078] In one example embodiment of this disclosure, parsing configuration files in the kernel build path and extracting compilation context information can be achieved through the following steps, specifically including: It can parse the autoconfiguration file in the kernel build path to obtain the configuration macros related to the target kernel module; convert the configuration macros into a set of macro definition parameters that the kernel module build system can recognize to obtain the kernel compilation macro definition parameters; and determine the kernel header file path based on the kernel build path.

[0079] The autoconfiguration configuration file (AMAC) is a file generated during kernel configuration or kernel build preparation to record kernel feature switches and architecture configuration states. For example, it could be an autoconfiguration header file located in the kernel build path. Configuration macros are configuration items formed by macro identifiers and their values ​​defined in the AMAC, used to represent kernel functions that are enabled, disabled, or have specific values ​​in the current kernel build environment. Since target kernel modules typically depend on kernel feature switches, architecture conditions, and the module compilation environment during compilation, parsing the AMAC to obtain configuration macros related to the target kernel module allows the target kernel module to have a conditional compilation context consistent with the kernel build environment during subsequent compilation and code indexing.

[0080] The autoconfiguration file can be located within the established kernel build path, and its macro definitions can be read and parsed. For example, macro definitions can be retrieved line by line, identifying the macro names and values ​​representing kernel configuration items. Kernel configuration items with specific prefixes can be extracted as candidate macros. During extraction, candidate macros can be filtered based on the source code list of the target kernel module and the dependencies between the target kernel module and its dependent objects, retaining those relevant to the target kernel module's compilation. For instance, macros related to multiprocessor support, target architecture, driver dependencies, module loading capabilities, or kernel subsystem interfaces can be identified as relevant to the target kernel module; configuration items unrelated to the target kernel module can be excluded from the subsequent macro definition parameter set construction.

[0081] Optionally, the automatic configuration file can be uniformly parsed through the kernel environment detection module, and the parsing results can be cached as a set of configuration macros for reuse in subsequent kernel build intermediate data, index targets, and compilation metadata generation processes. Alternatively, the original names and value states of the configuration macros can be preserved during automatic configuration file parsing, enabling subsequent conversion processes to generate corresponding macro definition parameters based on different macro value types. For example, for configuration macros that only indicate an enabled state, macro definitions without explicit values ​​can be formed; for configuration macros with numeric, string, or boolean values, their corresponding values ​​can be preserved so that subsequent build systems or code indexing tools can correctly identify conditional compilation branches. This embodiment does not impose special limitations on the specific file name of the automatic configuration file, the configuration macro filtering strategy, or the caching form of the configuration macros.

[0082] A macro parameter set refers to a collection of parameters that can be recognized by the kernel module build system or compiler. These parameters are used to pass kernel configuration state to the source file during the compilation of the target kernel module. Kernel compilation macro parameters are compilation parameters that have been transformed from configuration macros and can directly participate in the compilation and code indexing of the target kernel module. Configuration macros typically exist as macro definitions in autoconfiguration files, but the kernel module build system requires parameters that can be recognized by the compilation commands. Therefore, configuration macros need to undergo format conversion and parameterization.

[0083] The acquired configuration macros can be parsed one by one, and corresponding macro definition parameters can be generated based on the macro's name, value type, and activation status. For example, a configuration macro indicating that a certain kernel function is enabled can be converted into a compilation parameter with the macro name; for configuration macros with specific numerical or string values, both the macro name and its value can be converted into compilation parameters; configuration items that are not enabled or do not participate in the target kernel module construction can be left out of the macro definition parameter set. The converted macro definition parameter set can be saved as a list, array, build variable, or target attribute, and injected into the virtual index target or passed to relevant build logic during subsequent build processes.

[0084] Furthermore, when generating kernel compilation macro definition parameters, the macro definition parameter set can be standardized. For example, duplicate macro definitions can be removed, macro name formats can be standardized, macro definition priorities related to the target kernel module can be preserved, and macro definition parameters can be organized in a format recognizable by the build system. For scenarios requiring consistency with module compilation semantics, preset module compilation flag macros or kernel compilation flag macros can be added to the macro definition parameter set, enabling the target kernel module's source code to enter conditional branches that match the actual kernel module compilation state during subsequent code parsing.

[0085] In one implementation, the macro definition parameter set can be stored as a build variable and injected into the index target as compilation parameters when the index target is created; alternatively, it can be written into the compilation command record corresponding to the source file when generating compilation metadata, enabling the integrated development environment to read the kernel compilation macro definition parameters during code parsing and indexing. The specific expression of the macro definition parameter set can be adjusted accordingly for different build tools or different versions of the kernel module build system. For example, it can be in the form of command-line macro definition parameters or target compilation definition attributes; this embodiment does not impose any special limitations on this. By converting configuration macros into a macro definition parameter set recognizable by the kernel module build system, the kernel configuration state in the automatic configuration file can be transformed into kernel compilation macro definition parameters that can be directly used in the subsequent build process. This ensures that the target kernel module obtains a consistent macro definition environment during compilation operations and code indexing, improving the accuracy of kernel module source code parsing and the standardization of build parameter passing.

[0086] The kernel header file path refers to a set of directory paths that include kernel interface definitions, architecture-related definitions, and automatically generated header files. The kernel header file path can be determined based on the kernel build path. For example, it can be obtained from the directory structure corresponding to the kernel build path, including general header file directories, architecture-related header file directories, and automatically generated header file directories, and these directory paths can be combined to form the kernel header file path. Optionally, the architecture-related header file directories can be filtered based on the processor architecture information corresponding to the target kernel module to ensure that the determined kernel header file path matches the runtime environment of the target kernel module.

[0087] By parsing the automatic configuration file in the kernel build path to obtain the configuration macros related to the target kernel module, and converting the configuration macros into a set of macro definition parameters that the kernel module build system can recognize, and determining the kernel header file path based on the kernel build path, the kernel configuration state and header file search scope can be extracted and converted into compilation context information that can directly participate in compilation and code parsing. This allows the kernel module to maintain a consistent compilation context during the build and code indexing process, thereby improving the accuracy of conditional compilation path identification and enhancing the standardization of build parameter passing.

[0088] In one example embodiment of this disclosure, the kernel source code information corresponding to the target kernel module to be built can be obtained through the following steps, which may specifically include: It can receive module definition instructions for a target kernel module, parse the module definition instructions, and obtain a list of source code and the dependencies between the target kernel module and its dependent objects.

[0089] Module definition instructions are input instructions provided by developers or build scripts to describe the composition and dependencies of a target kernel module. They can exist in the form of function calls, configuration statements, or build script parameters. Module definition instructions can include the module name, a set of source files, and dependency information, representing the basic structure of the target kernel module. Kernel source code information is a data set formed after parsing the module definition instructions. It is used to establish a unified data representation between upper-level module definitions and subsequent build processing, and can include a list of the target kernel module's source code and the dependencies between the target kernel module and its dependent objects.

[0090] The module definition instructions can be received through a packaged module definition interface. For example, a pre-defined module definition interface can be called in the build script, passing in a set of source files and a set of dependent objects as parameters. After receiving the module definition instructions, they can be parsed, that is, the parameters in the module definition instructions can be parsed and semantically extracted to obtain the source code list and the dependencies between the target kernel module and its dependent objects. Here, the source code list refers to the complete set of source files contained in the target kernel module, which may include the main module source files, auxiliary implementation source files, and utility function files, etc.; dependencies refer to the associations between the target kernel module and other modules, libraries, or common components that the target kernel module depends on during the build process.

[0091] When parsing module definition instructions, source file paths can be standardized, such as converting relative paths to absolute paths or unifying path formats for subsequent processing. For dependency information, the names and types of dependencies, as well as the dependency direction between the target kernel module and the dependencies, can be parsed and converted into an internally unified representation. Furthermore, input parameters can be validated during parsing, such as checking if the source file exists or if the dependencies are defined, to prevent anomalies during the subsequent build process.

[0092] The source code list is used to uniformly describe the source file composition of the target kernel module during subsequent build processes. It serves as input data for generating intermediate kernel build data, creating index targets, and building entity targets. In specific implementations, the set of source files parsed from the module definition instructions can be directly used as the source code list, or the source file set can be further processed to obtain the source code list. For example, files in the source file set can be filtered to retain source file types that meet the kernel module compilation requirements; the source file set can be sorted or deduplicated to ensure the consistency of the source code list; and the source file set can be grouped and managed according to build requirements, such as distinguishing between main module files and auxiliary files. This embodiment does not impose special limitations on the specific organization method of the source code list.

[0093] Optionally, during the generation of the source code list, source files can be associated with their corresponding build attributes, such as recording compilation options or module information, for use in subsequent build processes. The source code list can also be stored as a target attribute in the build system, allowing for unified access and reuse across different build stages. By parsing the source code list based on module definition instructions, the composition of source files for the target kernel module can be uniformly expressed, thus avoiding repeated parsing of source file information in different build stages and improving the consistency and data reuse capabilities of the build process.

[0094] The dependency between a target kernel module and its dependent objects refers to the association between the target kernel module and other modules, libraries, or components it depends on during the build process. It characterizes the build order, dependency constraints, and change propagation relationships. Dependency object information is a parsed set of data describing dependent objects and their relationships. By processing this dependency object information, the dependencies between the target kernel module and its dependent objects can be formed.

[0095] The external modules or components that a target kernel module depends on can be determined based on the set of dependent objects in the dependency object information, and the dependency relationships between the target kernel module and each dependent object can be established. For example, the target kernel module can be set to depend on certain common components, so that the construction of these components is completed first during the build process; dependencies can also be used to control the build order, so that the target kernel module performs the compilation operation only after its dependent objects are completed. Dependencies can also be used to determine the build trigger logic when source files change, such as automatically triggering the rebuild of the target kernel module when dependent objects change. The target dependency mechanism in the build system can be used to manage dependency relationships, such as making dependencies automatically effective in the build system through dependency declarations between build targets; or dependencies can be represented as a directed graph structure to facilitate dependency analysis and optimization in complex dependency scenarios.

[0096] By receiving and parsing the module definition instructions for the target kernel module to obtain the source file list and dependency information, the source code list is further determined based on the source file list, and the dependency relationship is determined based on the dependency information. This allows the source file composition and dependency structure of the target kernel module to be expressed in a structured way, thereby enabling the build process to manage source files and dependencies based on a unified data description, thus improving the consistency of the build logic and enhancing the maintainability of the build in scenarios with multiple source files and multiple dependencies.

[0097] In one example embodiment of this disclosure, the following steps can be used to generate intermediate kernel build data that conforms to the kernel module build specification based on the source code list and dependencies. Specifically, these steps may include: Based on the source code list and dependencies, the module composition relationship corresponding to the target kernel module can be determined. The module composition relationship is used to represent the correspondence between the target kernel module and the source files involved in compilation. The module composition relationship is written into the intermediate build file according to the syntax form that the kernel module build system can recognize, so as to obtain kernel build intermediate data that conforms to the kernel module build specification.

[0098] The intermediate data for kernel building can include intermediate build files, which are description files conforming to the kernel module build system specification. These intermediate build files establish a connection between the upper-level build information of the target kernel module and the kernel module build system, enabling the kernel module build system to identify the module composition of the target kernel module based on the intermediate build files and perform subsequent compilation operations. Since the kernel module build system needs to identify the module target corresponding to the target kernel module and which source files participated in the compilation of that module target during the compilation operation, the module composition relationship of the target kernel module can be determined first based on the source code list and dependencies.

[0099] Module composition relationships can be used to characterize the correspondence between a target kernel module and the source files involved in compilation. For example, a module composition relationship can include the composition relationship between the module target corresponding to the target kernel module and each source file in the source code list, enabling the kernel module build system to know which source files' target files constitute the target kernel module. For a target kernel module consisting of a single source file, the module composition relationship can characterize the correspondence between the target kernel module and that single source file; for a target kernel module consisting of multiple source files, the module composition relationship can characterize the combination relationship between the target kernel module and the multiple source files, allowing multiple source files to be organized into a single kernel module target file during subsequent compilation and linking.

[0100] After determining the module composition relationships, these relationships can be written into intermediate build files according to a syntax form recognizable by the kernel module build system. This kernel-recognizable syntax form refers to the build description form that can be parsed and used by the kernel module build system to execute module compilation. It can be used to declare the module object to be built and its corresponding source or object files. By writing the module composition relationships into intermediate build files, the source code list and dependencies can be converted into input content that the kernel module build system can directly recognize.

[0101] In practice, intermediate build files can be generated in the build directory, and the module composition relationship can be written into these intermediate build files. These intermediate build files can be separated from the source code directory to avoid interference from the generated build content. Furthermore, corresponding intermediate build files can be generated for different build configurations, different processor architectures, or different kernel build paths, ensuring that the intermediate build files are compatible with the current build environment.

[0102] Intermediate build files can also be bound to the source code list and dependencies. When the source code list changes, dependencies change, or the module composition of the target kernel module changes, the intermediate build files can be regenerated to ensure that the content of the intermediate build files remains consistent with the build requirements of the current target kernel module.

[0103] By determining the module composition relationship of the target kernel module based on the source code list and dependencies, and writing the module composition relationship into the intermediate build file according to the syntax form that the kernel module build system can recognize, the kernel build intermediate data that conforms to the kernel module build specification can be obtained. This allows the source code composition and dependency association of the target kernel module to be converted into an input form that the kernel module build system can recognize. This improves the automation, standardization and traceability of build file generation while maintaining the compatibility of the original compilation mechanism of the kernel module build system.

[0104] In one example embodiment of this disclosure, it can be achieved through Figure 3 The steps outlined in the document involve determining the module composition relationship corresponding to the target kernel module based on the source code list and dependencies, referring to... Figure 3 As shown, it can specifically include: Step S310: Generate module target definition information based on the source code list; Step S320: Generate target file mapping relationships based on each source file in the source code list; Step S330: Generate dependency target declaration information based on the dependencies; Step S340: Determine the module composition relationship corresponding to the target kernel module based on the module target definition information, target file mapping relationship and dependency target declaration information.

[0105] The module target definition information refers to the descriptive information used to characterize the module compilation targets corresponding to the target kernel module under the kernel module build specification. It informs the kernel module build system about the module object to be generated. The source code list is the collection of source files that the target kernel module participates in the compilation, which may include main driver source files, function implementation source files, and auxiliary tool source files. Because the kernel module build system needs to identify the module target to be generated before performing the compilation operation, and then further determine which source files constitute the target module, the module target definition information of the target kernel module needs to be clarified based on the source code list before generating intermediate build files that conform to the kernel module build specification.

[0106] Module target definition information can be generated based on the target kernel module's module name and source code list. For example, when the target kernel module is defined as a driver module, the corresponding module target object can be determined based on the module name, and this module target object can be written into the target declaration content of the intermediate build file. For a target kernel module composed of multiple source files, the module target definition information does not need to list all source files one by one. Instead, it first determines the final module object to be generated, enabling the kernel module build system to understand the overall target of this build. Based on this, subsequent target file mapping relationships are used to further explain which source files' intermediate objects are compiled into this module object.

[0107] In one optional implementation, the module target definition information can be generated according to the target declaration syntax that the kernel module build system can recognize, such as forming a module object declaration based on the name of the target kernel module; alternatively, during the generation process, the module target definition information can be verified for consistency by combining the module name, source code list, and dependencies in the kernel source code information to ensure that the module target definition information matches the actual source code composition. If there is a correspondence between the name of the target kernel module and the name of the main source file, the module target definition information can be generated directly based on this name relationship; if the name of the target kernel module is specified by the developer in the module definition instruction, the specified name can be used first to form the module target definition information, and this embodiment does not impose any special limitations on this.

[0108] Object file mapping refers to information describing the correspondence between each source file in the source code list and its compiled object file. Source files typically exist as source code files, but during the actual compilation process, the kernel module build system first compiles each source file into its corresponding object file, and then combines these object files based on the module target definition information. Therefore, simply generating module target definition information is insufficient to fully describe the build structure of the target kernel module; it is also necessary to further convert each source file in the source code list into an object file composition relationship that the kernel module build system can understand.

[0109] The system can iterate through each source file in the source code list and generate corresponding target file identifiers based on the source file's filename, file path, or module information. For example, the source file extension in the source file name can be converted to the target file extension to obtain the target file name corresponding to that source file. For source files located in different directories, their relative path information can be preserved when generating the target file mapping relationship to ensure that the kernel module build system can find or generate the corresponding target file in the correct directory. Furthermore, if the source code list contains multiple source files, the target files corresponding to each source file can be aggregated according to module composition rules, so that they all point to the module target definition information.

[0110] Dependency target declaration information refers to descriptive information used to characterize the build association between a target kernel module and its dependent objects. Dependencies can be used to characterize the relationship between a target kernel module and common components, other modules, library files, or other build objects. When generating dependency target declaration information, dependency declaration content that can be recognized by the kernel module build system or upper-level build process can be generated based on the name and type of the dependent object and the dependency direction between the target kernel module and the dependent object.

[0111] For example, when a target kernel module depends on a common component, dependency target declaration information can be generated based on the build target corresponding to that common component, enabling the target kernel module to establish build order constraints with that common component during the build process. When a target kernel module depends on other modules or library files, dependency target declaration information can be generated based on the target name, output path, or interface declaration information of that module or library file, ensuring that subsequent compilation operations can be performed only after the dependent objects are complete or available. In an optional implementation, dependency target declaration information can be expressed in the form of target dependency declarations, lists of dependent objects, dependency graph nodes, or build attributes; this embodiment does not impose any special limitations on this. Dependency target declaration information can be used to control the build order between the target kernel module and its dependent objects, and can also be used to trigger a rebuild of the target kernel module when the dependent objects change, thereby maintaining build consistency between the target kernel module and its dependent objects.

[0112] The module composition relationship can be determined based on the module target definition information, target file mapping relationship, and dependency target declaration information. Among them, the module target definition information describes the module target to be generated, the target file mapping relationship describes which source files correspond to the target files that make up the module target, and the dependency target declaration information describes the build association between the module target and its dependent objects.

[0113] Module composition relationships can be used to generate intermediate kernel build data. Kernel build intermediate data can include intermediate build files, which act as a bridge between the source code list, dependencies, and the underlying kernel module build system of the target kernel module. In other words, module target definition information addresses which module target needs to be generated; target file mapping relationships address which source files correspond to which target files constitute the module target; dependency target declaration information addresses how the module target is associated with its dependent objects; and module composition relationships integrate these three elements according to kernel module build specifications into a composition description that can be subsequently written into intermediate build files.

[0114] In practical implementation, the module target definition information can be first used as the target declaration part in the module composition relationship, enabling the kernel module build system to identify the module object corresponding to the target kernel module. Then, the target file mapping relationship can be used as the source file component in the module composition relationship, enabling the kernel module build system to organize the compilation and linking process of the target kernel module according to the target files corresponding to each source file. Alternatively, the dependency target declaration information can be used as the dependency declaration part in the module composition relationship, so that the dependency between the target kernel module and its dependent objects can be identified and invoked during the build process.

[0115] For a target kernel module consisting of a single source file, the module composition relationship can contain only the module target declaration and the target object information corresponding to the source file; for a target kernel module consisting of multiple source files, the module composition relationship can further include the composition relationship between the multiple target files, so that these target files can be combined into the same kernel module target file; for a target kernel module with dependent objects, the module composition relationship can further include dependent target declaration information to characterize the construction constraints between the target kernel module and its dependent objects.

[0116] When determining the composition of modules, consistency checks can be performed on module target definition information, target file mapping relationships, and dependency target declaration information. For example, it can be checked whether the module target definition information is consistent with the module name of the target kernel module, whether the target files in the target file mapping relationship can be converted from the source files in the source code list, and whether the dependency objects in the dependency target declaration information have been defined or can be recognized by the build system.

[0117] Furthermore, to ensure that module composition conforms to the kernel module build specification, module target definition information, target file mapping relationships, and dependency target declaration information can be organized according to the syntax expected by the kernel module build system when generating module composition relationships. For example, the target kernel module can be declared as the module object to be built, the target files corresponding to each source file can be declared as the component objects of this module object, and the dependency target declaration information can be declared as the build constraint information associated with this module object. In this way, developers do not need to directly write complex build scripts, nor do they need to manually maintain the object mapping relationships between multiple source files, so that the source code composition and dependency constraints can be uniformly organized into module composition relationships.

[0118] By generating module target definition information based on the source code list, generating target file mapping relationships based on each source file in the source code list, and generating dependency target declaration information based on dependencies, and further determining the module composition relationship corresponding to the target kernel module based on the module target definition information, target file mapping relationships, and dependency target declaration information, the source code composition and dependency structure of the target kernel module can be automatically converted into an input form that the kernel module build system can recognize. This allows the module target, source file composition relationship, and dependency constraints to be accurately expressed, thereby reducing the complexity of manually maintaining build files and improving the standardization and traceability of build file generation.

[0119] In one example embodiment of this disclosure, before invoking the kernel module build system to perform compilation operations for the target kernel module based on kernel build intermediate data and kernel build path, an entity build target can be constructed, and the kernel module build system can be triggered to perform compilation operations through the entity build target. Specifically, this may include: Based on the source code list and dependencies, entity build targets for performing compilation operations can be constructed; intermediate kernel build data can be associated with entity build targets to trigger the kernel module build system to perform compilation operations through entity build targets.

[0120] Entity build targets are the build targets used to trigger the actual compilation process of the target kernel module. They can serve as execution units in the upper-level build process, invoking the kernel module build system and generating the kernel module object files corresponding to the target kernel module. Unlike index targets used for code indexing, entity build targets are primarily oriented towards the actual compilation output of the target kernel module, carrying the compilation triggering logic, input dependencies, and the relationships between output artifacts.

[0121] In practical implementation, the entity build target can be built based on the source code list and its dependencies. For example, each source file in the source code list can be used as the input file for the entity build target, enabling the entity build target to be aware of the source file composition of the target kernel module. Furthermore, the dependencies between the target kernel module and its dependent objects can be used as the build dependencies of the entity build target, ensuring that the entity build target follows the corresponding build order and dependency constraints during compilation. When the source files in the source code list change, or the dependent objects change, the entity build target can trigger a recompilation of the target kernel module, thereby maintaining consistency between the build result and the input state.

[0122] Kernel build intermediate data can include intermediate build files, which describe the module composition relationships of the target kernel module in a syntax recognizable by the kernel module build system. Associating kernel build intermediate data with the entity build target allows the entity build target to use this data as one of the inputs to the kernel module build system when it is executed. This triggers the kernel module build system to read the kernel build intermediate data and perform the compilation operation for the target kernel module based on the module composition relationships recorded within it.

[0123] For example, in an entity build target, a compilation instruction for invoking the kernel module build system can be configured, carrying the kernel build path and the path to the intermediate build files corresponding to the kernel build intermediate data. When the entity build target is triggered, this compilation instruction can be executed, causing the kernel module build system to read the intermediate build files in the environment corresponding to the kernel build path, and compile and link each source file in the source code list, thereby generating the kernel module object file corresponding to the target kernel module.

[0124] In one optional implementation, the entity build target can be set as a target in the default build process, so that the target kernel module can be automatically compiled along with the overall build process; or it can be set as a target that needs to be explicitly triggered by the developer so that the target kernel module can be built separately in debugging or local build scenarios. This embodiment does not impose any special limitations on the triggering method of the entity build target in the build process, as long as the entity build target can trigger the kernel module build system to perform compilation operations based on the kernel build intermediate data.

[0125] By building entity build targets based on source code lists and dependencies to perform compilation operations, and by associating kernel build intermediate data with entity build targets, the source code composition, dependency constraints, and kernel build intermediate data of the target kernel module can be incorporated into the compilation triggering process. This allows the kernel module build system to perform compilation operations under the triggering of entity build targets, reducing the complexity of manually calling build commands and improving the automation, controllability, and traceability of the build process.

[0126] In one example embodiment of this disclosure, it can be achieved through Figure 4 The steps described in the document are to create a virtual index target corresponding to the target kernel module. Refer to [link / reference]. Figure 4 As shown, it can specifically include: Step S410: Create a build target for the object type and set the build target for the object type to not participate in the default build process; Step S420: Associate the source code list with the construction target of the object type to obtain the virtual index target.

[0127] In this context, an object-type build target refers to an intermediate build target that carries the compilation attributes of source files but does not directly generate the final loadable kernel module object file. This object-type build target can be associated with the source code list of the target kernel module, enabling the build system to generate corresponding compilation commands and parameter records around each source file in the source code list. Since this object-type build target in this embodiment is primarily used to form the compilation context required for code indexing, rather than to replace the entity build target in performing kernel module compilation operations, it needs to be set to not participate in the default build process.

[0128] During the build target encapsulation process, an auxiliary build target name can be generated based on the target kernel module's module name, and an object-type build target can be created based on this auxiliary build target name. The object-type build target can be associated with the target kernel module's source files, but its output is not used as the final build artifact of the target kernel module. Furthermore, through the build system's exclusion attributes or non-default build attributes, the object-type build target can be set not to automatically participate in compilation with the default build command. In this way, during the default build process, the actual compilation operation is still triggered by the entity build target, ultimately generating the kernel module object file; while the object-type build target only retains the target attributes used to generate compilation commands, compilation parameters, and code index information.

[0129] In some optional implementations, the build target for an object type can be named an index target or shadow target corresponding to the target kernel module for differentiation and management within the build script. For example, a suffix indicating its indexing purpose can be appended to the target kernel module name, thus forming a build target for the object type that is independent of the entity build target. This naming convention does not affect the final output name of the target kernel module; it is only used internally by the build system to identify and maintain different build paths. At the same time, setting the build target for the object type to not participate in the default build process can also avoid conflicts between the object type's build target and the actual compilation process executed by the kernel module build system. This is especially important in scenarios where the kernel module requires special compilation rules, linking rules, or module post-processing rules to be handled by the native kernel module build system, ensuring that the actual build path still follows the kernel module build specifications.

[0130] Associating a source code list with a build target of an object type means using the source files involved in the build and indexing of the target kernel module as input to the object type's build target, thus maintaining a correspondence between the object type's build target and the source code composition of the target kernel module. A virtual index target, formed after associating the source code list with the object type's build target, is a build target used to carry the indexing context of the target kernel module's code. In other words, the object type's build target itself provides the target carrier, the source code list provides the specific range of source files, and the combination of the two forms a virtual index target corresponding to the target kernel module.

[0131] In practical implementation, a defined list of source files can be bound as the set of source files for the build target of an object type. The source files in the list can include the main source files, functional implementation source files, and auxiliary source files of the target kernel module. After binding, the build system can generate compilation command descriptions related to the build target of that object type for these source files, enabling subsequently injected compilation context information to apply to each source file in the list. This ensures that the scope of source files corresponding to the virtual index target remains consistent with the actual source code scope of the target kernel module, helping to avoid inconsistencies between the code index scope and the actual build scope.

[0132] Optionally, when associating the source code list with a build target of an object type, the source code list can be path normalized. For example, relative paths of source files can be converted into a unified path format relative to the current build directory or source code directory, so that the source file locations can be accurately recorded when generating compilation metadata later. For target kernel modules with a multi-directory organization structure, path information can also be preserved according to the original directory hierarchy of each source file in the source code list, so that the compilation metadata generated by the virtual index target can accurately correspond to the actual location of each source file. If the source code list contains source files dynamically parsed from kernel source code information, their source information can also be retained synchronously during the association process, so that the virtual index target can be updated accordingly when the source code list changes.

[0133] Furthermore, by associating the source code list with the build target of an object type, the build target of that object type can be managed separately from the entity build target. The entity build target is mainly responsible for generating kernel module object files, while the virtual index target is mainly responsible for generating compilation metadata. They share the source code list but perform different functions. Since the virtual index target does not participate in the default build process, it does not change the behavior of the entity build target in calling the kernel module build system; at the same time, since the virtual index target is associated with the same source code list, it can provide the integrated development environment with a code index range consistent with the real module source files.

[0134] By creating a build target of an object type and setting it to not participate in the default build process, and associating the source code list with the build target of that object type to form a virtual index target, an independent compilation context can be provided for the source code list without affecting the actual compilation path of the target kernel module. This allows compilation parameters to be uniformly organized around the virtual index target, thereby improving the information isolation between different paths in the build process. Furthermore, the virtual index target neither interferes with the generation of the actual build artifacts of the target kernel module, nor does it generate compilation metadata for code indexing around the same source code list, thereby improving the consistency between the compilation metadata and the actual source code composition of the target kernel module.

[0135] In one example embodiment of this disclosure, associating compilation context information with an index target associated with a source code list and generating compilation metadata for code indexing can be achieved through the following steps, specifically including: The kernel header file path can be set as the header file search path of the index target; kernel compiler macro definition parameters and preset kernel identifier macros can be added to the compilation parameters of the index target; and compilation metadata for code indexing can be generated based on the header file search path and compilation parameters.

[0136] The header file search path refers to the set of directory paths used to locate header files during source file compilation or code parsing. Since the target kernel module needs to reference a large number of kernel header files during compilation, such as kernel interface definitions, data structure declarations, and architecture-related header files, the kernel header file path needs to be explicitly set as the header file search path of the index target. This ensures that the source code list associated with the index target can carry the complete header file search scope when generating compilation commands. As a build target that carries compilation context information, the setting of the header file search path of the index target directly determines the completeness of the header file path information in subsequent compilation metadata.

[0137] The parsed set of kernel header file paths can be written into the compilation attributes of the index target. This allows the build system to append the kernel header file paths as header file search path parameters to the compilation call when generating compilation commands for the index target. Kernel header file paths can include general kernel header file directories, architecture-related header file directories, and automatically generated header file directories. For example, common header file directories located in the kernel build path and architecture directories corresponding to the target processor architecture information can be added to the header file search path list, ensuring that each source file in the source code list can correctly access kernel interface definitions and related data structures during parsing.

[0138] Optionally, kernel header file paths can be deduplicated, sorted, or prioritized to avoid duplicate paths or path conflicts affecting the generation of compilation commands. For example, architecture-specific header file paths can be prioritized over general header file paths, so that header file definitions related to the target architecture are matched first during compilation or parsing; alternatively, path source information can be retained in the path set for incremental adjustments when paths are updated.

[0139] By setting the kernel header file path as the header file search path of the index target, each source file in the source code list can have the same header file search range as the real kernel compilation environment when generating compilation metadata. This avoids code parsing anomalies caused by missing or inconsistent header file paths, and improves the accuracy and completeness of header file parsing during code indexing.

[0140] Compilation parameters refer to the set of parameters passed to the compiler during the compilation process, including macro definitions, compilation options, and other parameters used to control compilation behavior. Kernel compilation macro definitions are a set of macro definitions obtained by parsing and converting the autoconfiguration file; they represent the current kernel configuration state. Preset kernel identifier macros are macro definitions used to identify the current compilation environment as a kernel module compilation environment, such as compilation semantics used to distinguish between user-mode code and kernel-mode code. Adding kernel compilation macro definitions and preset kernel identifier macros to the compilation parameters of the index target ensures that the compilation commands generated by the index target fully reflect the macro definition environment during kernel module compilation.

[0141] In practical implementation, kernel compiler macro definitions can be written one by one into the compiler parameter attributes of the index target. This allows the build system to append these macro definitions as compiler parameters to the compiler call corresponding to each source file when generating the compiler command. Simultaneously, preset kernel identifier macros can be added to the compiler parameters to ensure that the source code enters the kernel module compilation semantics during parsing. For example, preset kernel identifier macros can be used to indicate that the current code is in a kernel module compilation context, thus enabling conditional compilation statements to correctly select the relevant kernel branches.

[0142] During the generation of compilation metadata, the header file search path and compilation parameters of the indexed target can be recorded one-to-one with the source files in the source code list, thus forming structured compilation metadata. For example, based on the build system's compilation command export mechanism, the compilation command, header file search path, and macro definition parameters corresponding to each source file can be written into a structured data file, making this structured data file readable by the integrated development environment. The compilation metadata can be organized using structured formats such as JSON, and each record can include information such as the source file path, compilation command, header file path, and macro definition parameters.

[0143] Optionally, macro definition parameters can be categorized and managed when added, for example, by distinguishing between kernel configuration macros, architecture macros, and module identifier macros, so that they can be organized by category when generating compilation metadata. Alternatively, macro definition parameters can be filtered to retain only those related to the target kernel module, thereby reducing the impact of redundant parameters on compilation commands. By adding kernel compilation macro definition parameters and preset kernel identifier macros to the compilation parameters of the virtual index target, each source file in the source code list can have macro definition conditions consistent with the real kernel module compilation environment when generating compilation metadata, thus ensuring the correctness of the conditional compilation path during code parsing and further improving the accuracy of functions such as code indexing, jumping, and auto-completion.

[0144] By setting the kernel header file path as the header file search path of the virtual index target, and adding kernel compilation macro definition parameters and preset kernel identifier macros to the compilation parameters of the index target, compilation metadata for code indexing is generated based on the header file search path and compilation parameters. This allows the index target associated with the source code list to fully carry the compilation context information of the target kernel module. Consequently, each source file in the source code list has a consistent header file search scope and macro definition environment when generating compilation metadata, thereby improving the consistency of context information during code parsing and enhancing the accuracy of code indexing results.

[0145] In one example embodiment of this disclosure, the following steps can be used to construct the target kernel module by invoking a kernel module build system based on kernel build intermediate data and the kernel build path: It can respond to compilation instructions used to invoke the kernel module build system, triggering the kernel module build system to read intermediate kernel build data and perform compilation operations for the target kernel module; wherein, the compilation instructions carry the kernel build path and the path of the intermediate build file corresponding to the intermediate kernel build data.

[0146] The compilation instructions refer to the set of commands used to trigger the kernel module build system to execute the compilation operation of the target kernel module. They are used to connect the intermediate kernel build data generated in the upper-level build process with the lower-level kernel module build system. The kernel module build system refers to the build mechanism provided in the Linux kernel source tree for building external modules. During execution, it needs to receive parameters such as the kernel build path and the path where the external module is located to complete the module compilation and linking.

[0147] Based on the determined kernel build path and the paths to intermediate build files corresponding to the generated intermediate kernel build data, compilation instructions conforming to the kernel module build system call specification can be constructed. For example, the kernel build path can be used as the working directory parameter of the build system, and the directory containing the intermediate build files can be used as the module build directory parameter, thus forming a complete compilation call command. When constructing this compilation instruction, architecture-related parameters can also be appended to the compilation instruction in conjunction with the determined build architecture parameters, enabling the compilation operation to adapt to the target processor architecture information. In addition, parallel compilation parameters or build mode parameters can be appended to the compilation instruction to further optimize the build process.

[0148] The compilation instructions can be encapsulated using a custom command mechanism within the build system, allowing them to exist as an execution unit within the build system. For example, the compilation instructions can be encapsulated as execution commands for the build target, and associated with the source code list of the target kernel module, intermediate kernel build data, and dependencies, so that the compilation instructions can be automatically triggered when relevant inputs change. Error handling mechanisms or log output mechanisms can also be added to the compilation instructions to record the execution status during the compilation process; this embodiment does not impose any special limitations on this.

[0149] Executing compilation instructions refers to the process where the build system or operating system command execution environment invokes compilation instructions, thereby triggering the kernel module build system to enter the compilation and execution phase. During this process, the kernel module build system first enters the corresponding build environment based on the kernel build path in the compilation instructions. Then, it treats the path containing the intermediate build files corresponding to the kernel build intermediate data as the external module directory, thereby reading the module composition relationships defined in the kernel build intermediate data.

[0150] Once the compilation instructions are executed, the kernel module build system identifies the module object corresponding to the target kernel module based on the module target definition information described in the kernel build intermediate data, and compiles each source file in the source code list one by one according to the object file mapping relationship. For each source file, the kernel module build system can call the underlying compiler to generate the corresponding object file; then, it links each object file according to the module target definition information, finally generating the kernel module object file corresponding to the target kernel module. Because the kernel build intermediate data has clearly described the relationship between source files and module targets, the kernel module build system can complete the compilation and linking of multi-source file modules without manual intervention.

[0151] Furthermore, the compilation order can be controlled by incorporating dependencies during the execution of compilation instructions. For example, when a target kernel module depends on other components or common code, the compiler can ensure that the relevant dependencies have been built before the compilation operation, thereby guaranteeing the correctness of the compilation process. Additionally, compilation logs, error messages, and warnings can be output during the compilation process to facilitate debugging and analysis by developers.

[0152] Compilation instructions can be optimized through the parallel execution mechanism of the build system, such as compiling multiple source files in parallel in a multi-core processor environment, thereby improving compilation efficiency. Alternatively, intermediate kernel build data can be validated before executing compilation instructions to ensure its content is consistent with the current source code list and dependencies. By responding to compilation instructions that invoke the kernel module build system, triggering the system to read intermediate kernel build data and execute compilation operations for the target kernel module, a module build process based on automatically generated intermediate build files can be implemented while maintaining the original kernel module build mechanism. This ensures that the compilation process of the target kernel module conforms to kernel module build specifications and integrates into the automated build system, thereby improving the standardization and execution efficiency of the build process.

[0153] By responding to compilation instructions that carry the kernel build path and the path to intermediate build files corresponding to the kernel build intermediate data, the kernel module build system is triggered to read the kernel build intermediate data and execute the compilation operation of the target kernel module. This enables the upper-layer build process to be effectively connected with the kernel module build system, thereby enabling the target kernel module build process to be automated while maintaining the original build mechanism, thus improving the standardization and execution efficiency of the build process.

[0154] In one example embodiment of this disclosure, the compilation operation for the target kernel module can be performed and the target kernel module can be built through the following steps, which may specifically include: It can build intermediate data based on the kernel, compile each source file in the source code list to generate intermediate object files; perform linking processing based on the intermediate object files to generate the kernel module object file corresponding to the target kernel module; and build the target kernel module based on the kernel module object file.

[0155] The intermediate kernel build data can record the module composition relationships corresponding to the target kernel module, such as module target definition information, target file mapping relationships, and dependency target declaration information. When the kernel module build system performs compilation operations for the target kernel module, it can read the intermediate kernel build data and determine the source files to be compiled and the corresponding target files for each source file based on the module composition relationships recorded therein.

[0156] The source files in the source code list can include the main module source files, function implementation source files, auxiliary tool source files, etc., of the target kernel module. The kernel module build system can use the intermediate kernel build data to compile each source file in the source code list separately, thereby generating intermediate object files corresponding to each source file. Intermediate object files are object files formed after the source files have been compiled, but which have not yet been combined into the final kernel module object file; they can be used as input for subsequent linking processes.

[0157] In practical implementation, the kernel module build system can determine the mapping relationship between each source file in the source code list and its corresponding intermediate object file based on the object file mapping relationship in the kernel build intermediate data. For example, for each source file in the source code list, the corresponding intermediate object file name can be determined based on its file name, file path, or object file mapping rules, and the compiler can be invoked to compile the source file and generate the corresponding intermediate object file. For source files located in different directories, their relative paths or build directory information can be preserved so that the intermediate object files can be generated and referenced in the correct locations.

[0158] After generating intermediate object files, linking can be performed based on these intermediate object files to generate the kernel module object file corresponding to the target kernel module. Linking refers to the process of combining multiple intermediate object files according to the module composition relationship of the target kernel module, and generating an object file that can be loaded as a kernel module or participate in subsequent module processing. For a target kernel module consisting of a single source file, the kernel module object file can be generated based on the intermediate object file corresponding to that single source file; for a target kernel module consisting of multiple source files, the intermediate object files corresponding to the multiple source files can be combined and linked to generate the same kernel module object file.

[0159] In practical implementation, the kernel module build system can determine the final module object to be generated based on the module target definition information in the intermediate kernel build data, and determine the set of intermediate target files to participate in linking based on the target file mapping relationship. Subsequently, the intermediate target files can be linked according to the kernel module build specification to obtain the kernel module target file corresponding to the target kernel module. If the target kernel module has dependent objects, the system can also confirm whether the relevant dependent objects have been built or are in a usable state based on the dependency target declaration information, to ensure that the linking process can be executed when the dependency conditions are met.

[0160] A kernel module object file is a build artifact corresponding to a target kernel module, generated after compilation and linking. Kernel module object files can be module files that can be loaded and executed by the kernel, or they can be object files used for subsequent module post-processing, symbol processing, or installation and deployment. Building a target kernel module based on a kernel module object file means that after the kernel module object file is generated, this object file is used as the result of the target kernel module build, and it can be further output to a preset build directory or used in subsequent loading, testing, and deployment processes.

[0161] By compiling each source file in the source code list based on intermediate kernel build data to generate intermediate object files, and then linking these intermediate object files to generate the kernel module object file corresponding to the target kernel module, the construction process of the target kernel module can form a complete closed loop from source file compilation, intermediate object file generation to kernel module object file output. Further, by completing the construction of the target kernel module based on the kernel module object file, the compilation operations in the claims can be explicitly applied to the actual construction output of the target kernel module, thereby improving the completeness, verifiability, and traceability of the construction process.

[0162] In one example embodiment of this disclosure, the compilation metadata may include a structured compilation metadata file; the synchronous export of compilation metadata based on the index target during the compilation operation can be achieved through the following steps, specifically including: During the compilation process, the compilation commands and parameters corresponding to the index target can be recorded; a compilation database structure can be built based on the compilation commands and parameters, and a structured compilation metadata file can be generated and exported based on the compilation database structure; the structured compilation metadata file is used to provide the header file path, macro definition parameters and compilation options corresponding to the source file to support code parsing, jumping and auto-completion functions.

[0163] The compilation commands refer to the command information generated by the build system for each source file in the source code list, describing how the source files are processed by the compiler. Compilation parameters are the set of parameters appended to the compilation commands, which may include header file search paths, macro definition parameters, compilation options, source file paths, and working directories. The compilation commands and parameters corresponding to the index target are not used to replace the kernel module build system in performing the actual compilation of the target kernel module, but rather to reflect the compilation context required by the source code list associated with the index target in the code indexing scenario. Since the index target is already associated with the source code list and associated with compilation context information, recording the compilation commands and parameters corresponding to this virtual index target allows the extraction of key information relied upon by the target kernel module source code during the parsing process.

[0164] During the compilation of the target kernel module, the build system can synchronously trigger the generation of compilation commands for the index target. For example, when the build system processes source files in the source code list based on the index target, it can generate corresponding compilation commands for each source file and record the header file search path, macro definition parameters, and other compilation options carried in the compilation command. The header file search path can come from the kernel header file path set to the virtual index target, and the macro definition parameters can come from the kernel compilation macro definition parameters added to the virtual index target and the preset kernel identifier macros.

[0165] The compilation commands and parameters corresponding to the index targets can be recorded through the compilation command export mechanism of the build system; alternatively, the build script can actively collect target attributes when generating the index targets and convert these attributes into a parameter set that can be subsequently written into the compilation database structure. For cases where the source code list contains multiple source files, the compilation commands and parameters corresponding to each source file can be recorded separately, giving each source file an independent parsing context. For target kernel modules with multi-directory organization structures, the absolute or relative paths of each source file can be retained when recording compilation commands, enabling the integrated development environment to accurately locate the source files. By recording the compilation commands and parameters corresponding to the index targets during the compilation process, the kernel header file paths, kernel compilation macro definition parameters, and preset kernel identifier macros carried in the virtual index targets can be further converted into exportable command-level data. This avoids the information required for code indexing existing only within the build script, improving the accessibility and completeness of compilation context information.

[0166] A compiler database structure refers to a data structure used to record the compilation context of source files according to preset data organization rules. It converts obtained compilation commands and parameters into a data format that can be recognized and read by development tools. A structured compiler metadata file is a file-based data generated based on the compiler database structure. It is used to centrally store the compilation context information corresponding to each source file in the source code list. Compared to parameter information scattered within build scripts or build systems, structured compiler metadata files can express the correspondence between source files, compilation commands, compilation parameters, and working directories in a unified format.

[0167] The compilation commands and parameters corresponding to each source file can be organized into a record item in the compilation database structure. This record item can include information such as the source file path, compilation command content, compilation parameter set, and the working directory corresponding to the execution of the compilation command. Header file search paths can be written into this record item as part of the compilation parameters; kernel compilation macro definition parameters and preset kernel identifier macros can also be written into this record item as macro definition parameters. Since this information all originates from the target attributes of the indexed target and the generated compilation commands, the compilation database structure can form a unified and complete code indexing context around the source code list of the target kernel module.

[0168] The structured compilation metadata file can be generated in JSON format, for example, recording compilation database entries corresponding to multiple source files as an array. Each compilation database entry may include source file fields, command fields, parameter fields, or directory fields. The order of fields, path formats, and parameter expressions in the structured compilation metadata file can also be adjusted according to the reading requirements of the integrated development environment or code analysis tools; this embodiment is not limited to these.

[0169] Furthermore, when generating structured compilation metadata files, compilation commands and parameters can be standardized. For example, duplicate header file search paths can be merged, macro definition parameters can be deduplicated, source file paths can be standardized, and path separators for different operating systems can be uniformly processed. Compilation commands generated from different build configurations can also be stored in isolation according to the target kernel module name or build directory to avoid confusion between compilation metadata from different kernel build paths, different processor architecture information, or different build architecture parameters. By constructing a compilation database structure based on compilation commands and parameters and generating structured compilation metadata files, the compilation context information carried by the index target can be converted into a structured file that development tools can directly read. This establishes a clear mapping relationship between source files and their header file search paths, macro definition parameters, and compilation options, improving the readability, reusability, and consistency of compilation metadata.

[0170] Exporting the structured compilation metadata file as compilation metadata means outputting the generated structured compilation metadata file to a preset location for external development tools to read and use during the development of the target kernel module. For example, the preset location can be the build directory corresponding to the target kernel module, or a project directory or a specified output directory that the integrated development environment can recognize. This embodiment does not impose special limitations on the export location of the structured compilation metadata file, as long as the integrated development environment can access the structured compilation metadata file.

[0171] A structured compilation metadata file can be written to the build output directory during or after the compilation process, and the file path can be recorded as part of the exported compilation metadata. If the build system supports automatic export of the compilation database, the structured compilation metadata file can be automatically generated and output during the build process by enabling the corresponding export options. If the build system does not directly support the target format, a custom conversion script can be used to convert the recorded compilation commands and parameters into a structured compilation metadata file before exporting. The exported compilation metadata can coexist with the build results of the target kernel module, where the kernel module target file is used for loading and execution, and the structured compilation metadata file is used for code parsing and indexing.

[0172] When exporting structured compilation metadata files, existing files can be overwritten and updated, or independent structured compilation metadata files can be generated under different build architecture parameters or different kernel build paths. For large projects, structured compilation metadata files corresponding to multiple target kernel modules can be merged to form a compilation metadata set covering the source files of multiple kernel modules; of course, they can also be exported separately for a single target kernel module to maintain clear module-level data boundaries, and this embodiment does not impose any special limitations on this.

[0173] The structured compilation metadata file provides the header file paths, macro definition parameters, and compilation options corresponding to the source files to support code parsing, jumping, and auto-completion. The header file paths refer to the kernel header file paths associated with each source file in the source code list. These paths enable the integrated development environment (IDE) to locate kernel interfaces, kernel data structures, and architecture-related declarations when parsing source files. Macro definition parameters refer to kernel compilation macro definitions and preset kernel identifier macros related to source file parsing. These parameters enable the IDE to identify valid code branches corresponding to conditional compilation statements. Compilation options further describe the compilation environment parameters required for source file parsing. The header file paths, macro definition parameters, and compilation options together constitute the code parsing context for the source files.

[0174] Specifically, after the integrated development environment (IDE) reads the structured compilation metadata file, it can locate the specific source file in the target kernel module based on the source file path, and load the required kernel header file according to the corresponding header file path. Furthermore, it can determine whether conditional compilation branches are effective based on macro definition parameters, thereby avoiding incorrectly identifying inactive code branches as valid code. Further, it can combine compilation options to perform semantic analysis, symbol resolution, and index building, enabling the IDE to obtain a parsing context matching the target kernel module's build environment based on the structured compilation metadata file, without needing to directly parse the complex build scripts within the kernel module's build system.

[0175] Structured compilation metadata files can be used to support code parsing, navigation, and auto-completion. Code parsing refers to the integrated development environment (IDE) performing syntactic and semantic analysis on source files based on header file paths, macro definition parameters, and compilation options. Navigation establishes navigation relationships between symbol definitions, function declarations, macro definitions, and reference locations based on the parsing results. Auto-completion provides options such as function, variable, structure member, or macro names based on the current context when the developer is editing code. Because structured compilation metadata files are directly derived from the compilation commands and parameters corresponding to the indexed target, they can reduce the deviation between the code parsing context and the actual build context of the target kernel module. By providing header file paths, macro definition parameters, and compilation options for the source files in the structured compilation metadata files, the originally scattered and implicit compilation context during the target kernel module build process can be converted into data readable by the IDE. This improves the accuracy of code parsing of kernel module source code, enhances the reliability of navigation and auto-completion functions, and further improves the development efficiency and code maintainability of complex kernel module projects.

[0176] By recording the compilation commands and parameters corresponding to the index target during the compilation process, and constructing a compilation database structure based on the compilation commands and parameters, a structured compilation metadata file is generated and exported. This allows the compilation context information involved in the build process to be extracted from the build system and provided to the outside in a structured form. This establishes a clear mapping relationship between the source file and its header file path, macro definition parameters, and compilation options, thereby improving the accessibility of compilation context information and enhancing the reliability of code parsing, jumping, and auto-completion functions.

[0177] Figure 5 The illustration shows a schematic diagram of the process of building kernel modules and generating code indexes based on CMake according to some embodiments of the present disclosure.

[0178] refer to Figure 5 As shown, in step S501, the developer writes a CMakeLists.txt file to define the source files, dependencies, and build parameters of the target kernel module; then, in step S502, the CMake configuration phase is executed, the CMakeLists.txt file is parsed, and the kernel source code information and build processing information required by the build system are generated; in step S503, the target is processed, and the virtual index target path and the entity build target path are entered according to the build logic branch.

[0179] In the virtual index path, firstly, in step S504, a Shadow Target is created. This target is an object type construction target and does not participate in the default construction process. Then, in step S505, the kernel header file path and kernel compilation macro definition parameters are injected into the virtual index target to build a compilation context consistent with the kernel compilation environment. In step S506, a compile_commands.json file, i.e., a structured compilation metadata file, is generated based on the virtual index target. Then, in step S507, an integrated development environment (IDE), such as Visual Studio Code (VS Code) or CLion, implements code completion, definition jump, and semantic parsing functions based on the compile_commands.json file.

[0180] Meanwhile, in the entity build path, the CMake configuration phase continues in step S508 to generate the kernel build intermediate data corresponding to the entity build target; in step S509, a Custom Command is created to encapsulate the calling logic of the kernel module build system; then in step S510, the kernel module build system is called by executing the command make -CKERNEL_SRC, where KERNEL_SRC is the kernel build path, so that the kernel module build system reads the intermediate build file corresponding to the kernel build intermediate data and performs the compilation operation; finally, in step S511, the corresponding kernel module target file, i.e., the .ko file, is generated.

[0181] Figure 6 The illustration shows a timing flow diagram of kernel module building and compilation metadata generation based on CMake according to some embodiments of the present disclosure.

[0182] refer to Figure 6 As shown, the process of building kernel modules and generating compilation metadata based on CMake can be composed of developer 610, CMake build system 620, file system 630, and Linux Kbuild 640. Specifically: In step S601, developer 610 initiates a build request for the target kernel module to CMake build system 620 by calling the add_kernel_module function and passing in the source file set (srcs) and dependency object information; then in step S602, CMake build system 620 parses the source file list and its dependencies to obtain the source code list for subsequent build processing and the dependencies between the target kernel module and its dependent objects.

[0183] Based on this, the construction phase of the virtual index target and the entity construction target begins. In step S603, the CMake build system 620 creates a construction target for the object type, that is, it generates an object type construction target that does not participate in the default construction process by using the add_library(OBJECT EXCLUDE_FROM_ALL) method; then in step S604, the kernel header file path is set to the object type construction target, that is, the kernel header file path is injected by target_include_directories; subsequently, in step S605, kernel compilation macro definition parameters (such as _KERNEL_, etc.) and preset kernel identifier macros are added to the object type construction target by target_compile_definitions, thereby constructing a compilation context consistent with the kernel compilation environment.

[0184] Meanwhile, in step S606, the CMake build system 620 automatically generates a Kbuild file that conforms to the kernel module build specification based on the source code list and dependencies. This Kbuild file can be used as an intermediate build file corresponding to the kernel build intermediate data and is stored through the file system 630. Further, in step S607, a custom build command for calling the kernel module build system is created, that is, the make modules call logic is encapsulated by add_custom_command, thereby forming an entity build target.

[0185] After completing the above target build configuration, in step S608, the developer 610 executes the cmake --build command to trigger the build process; then in step S609, the CMake build system 620 calls the make -C command through a custom build command to enter the kernel build path, thereby triggering the Linux kernel build system Linux Kbuild 640 to perform the compilation operation; in step S610, the Linux kernel build system Linux Kbuild 640 reads the Kbuild file generated in the file system 630 and executes the compilation process according to the module target definition information, target file mapping relationship and dependency target declaration information therein; finally, in step S611, the corresponding kernel module target file, i.e., the .ko file, is generated.

[0186] Through the above-described sequence process, kernel source code information acquisition, virtual index target construction, kernel construction intermediate data generation, and kernel module compilation and execution can be completed within the same build system. This allows the code index path and the actual construction path to be completed collaboratively in the same process, thereby achieving unified support for automatic kernel module construction and code parsing.

[0187] It should be noted that although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0188] Furthermore, in this example embodiment, a kernel module construction apparatus is also provided. (Refer to...) Figure 7 As shown, the kernel module construction apparatus 700 includes: a kernel environment detection module 710, an intermediate file generation module 720, an index metadata generation module 730, a compilation and execution module 740, and a metadata export module 750. Wherein: The kernel environment detection module 710 is used to obtain the kernel source code information and build environment information corresponding to the target kernel module to be built. The kernel source code information includes the source code list of the target kernel module and the dependencies between the target kernel module and its dependent objects. The build environment information includes the kernel build path of the target kernel module and the compilation context information. The intermediate file generation module 720 is used to generate kernel build intermediate data that conforms to the kernel module build specification based on the source code list and dependencies. The index metadata generation module 730 is used to associate compilation context information with the index target associated with the source code list and generate compilation metadata for code indexing; The compilation and execution module 740 is used to call the kernel module build system to perform compilation operations for the target kernel module based on kernel build intermediate data and kernel build path, and build the target kernel module. The metadata export module 750 is used to synchronously export compilation metadata based on the index target during the compilation process, so that the integrated development environment can perform code parsing and indexing.

[0189] In some example embodiments of this disclosure, based on the foregoing scheme, the kernel build intermediate data includes intermediate build files; the intermediate file generation module 720 is configured to: determine the module composition relationship corresponding to the target kernel module according to the source code list and dependencies, the module composition relationship is used to characterize the correspondence between the target kernel module and the source files involved in compilation; and write the module composition relationship into the intermediate build file according to the syntax form recognizable by the kernel module build system to obtain kernel build intermediate data that conforms to the kernel module build specification.

[0190] In some example embodiments of this disclosure, based on the foregoing scheme, the intermediate file generation module 720 is configured to: generate module target definition information according to the source code list; generate target file mapping relationships according to each source file in the source code list; generate dependency target declaration information according to dependencies; and determine the module composition relationship corresponding to the target kernel module according to the module target definition information, target file mapping relationships and dependency target declaration information.

[0191] In some example embodiments of this disclosure, based on the foregoing scheme, before calling the kernel module build system to perform compilation operations for the target kernel module based on kernel build intermediate data and kernel build path, the compilation execution module 740 is configured to: build an entity build target for performing compilation operations based on the source code list and dependencies; associate the kernel build intermediate data with the entity build target so as to trigger the kernel module build system to perform compilation operations through the entity build target.

[0192] In some example embodiments of this disclosure, based on the foregoing scheme, the index target includes a virtual index target; before associating the compilation context information with the index target associated with the source code list to generate compilation metadata for code indexing, the index metadata generation module 730 is configured to: create a build target of object type and set the build target of object type to not participate in the default build process; associate the source code list with the build target of object type to obtain a virtual index target.

[0193] In some example embodiments of this disclosure, based on the foregoing scheme, the compilation context information includes the kernel header file path and kernel compilation macro definition parameters; the index metadata generation module 730 is configured to: set the kernel header file path as the header file search path of the index target; add the kernel compilation macro definition parameters and preset kernel identifier macros to the compilation parameters of the index target; and generate compilation metadata for code indexing based on the header file search path and compilation parameters.

[0194] In some example embodiments of this disclosure, based on the foregoing scheme, the compilation execution module 740 is configured to: in response to a compilation instruction for invoking the kernel module build system, trigger the kernel module build system to read kernel build intermediate data and perform a compilation operation for the target kernel module; wherein, the compilation instruction carries the kernel build path and the intermediate build file path corresponding to the kernel build intermediate data.

[0195] In some example embodiments of this disclosure, based on the foregoing scheme, the compilation and execution module 740 is configured to: compile each source file in the source code list based on kernel construction intermediate data to generate intermediate object files; perform linking processing based on the intermediate object files to generate kernel module object files corresponding to the target kernel module; and construct the target kernel module based on the kernel module object files.

[0196] In some example embodiments of this disclosure, based on the foregoing scheme, the compiled metadata includes a structured compiled metadata file; the metadata export module 750 is configured to: record the compilation commands and compilation parameters corresponding to the index target during the compilation operation; construct a compiled database structure based on the compilation commands and compilation parameters; and generate and export a structured compiled metadata file according to the compiled database structure; wherein, the structured compiled metadata file is used to provide the header file path, macro definition parameters and compilation options corresponding to the source file to support code parsing, jumping and auto-completion functions.

[0197] In some example embodiments of this disclosure, based on the foregoing scheme, the kernel environment detection module 710 is configured to: obtain processor architecture information of the runtime environment corresponding to the target kernel module; determine the build architecture parameters of the target kernel module based on the processor architecture information; search for the kernel build path according to a preset search path or a user-specified path based on the build architecture parameters; and parse the configuration files in the kernel build path to extract compilation context information.

[0198] In some example embodiments of this disclosure, based on the foregoing scheme, the compilation context information includes the kernel header file path and kernel compilation macro definition parameters, and the configuration file includes an automatic configuration file; the kernel environment detection module 710 is configured to: parse the automatic configuration file in the kernel build path to obtain the configuration macros related to the target kernel module; convert the configuration macros into a set of macro definition parameters that the kernel module build system can recognize to obtain the kernel compilation macro definition parameters; and determine the kernel header file path based on the kernel build path.

[0199] In some example embodiments of this disclosure, based on the foregoing scheme, the kernel environment detection module 710 is configured to: receive module definition instructions for the target kernel module; parse the module definition instructions to obtain a source code list and the dependencies between the target kernel module and its dependent objects.

[0200] The specific details of each module in the kernel module construction device described above have been described in detail in the corresponding kernel module construction methods, so they will not be repeated here.

[0201] It should be noted that although several modules or units of the kernel module construction apparatus have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0202] Furthermore, in an exemplary embodiment of this disclosure, an electronic device capable of implementing the above-described method for constructing a kernel module is also provided.

[0203] Those skilled in the art will understand that various aspects of this disclosure can be implemented as a system, method, or program product. Therefore, various aspects of this disclosure can be embodied in the following forms: a completely hardware embodiment, a completely software embodiment (including firmware, microcode, etc.), or an embodiment combining hardware and software aspects, collectively referred to herein as a "circuit," "module," or "system."

[0204] The following reference Figure 8 To describe an electronic device 800 according to such an embodiment of the present disclosure. Figure 8 The electronic device 800 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0205] like Figure 8 As shown, the electronic device 800 is presented in the form of a general-purpose computing device. The components of the electronic device 800 may include, but are not limited to: at least one processing unit 810, at least one storage unit 820, a bus 830 connecting different system components (including storage unit 820 and processing unit 810), and a display unit 840.

[0206] The storage unit stores program code that can be executed by the processing unit 810, causing the processing unit 810 to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure. For example, the processing unit 810 can perform actions such as... Figure 1 Step S110 shows obtaining the kernel source code information and build environment information corresponding to the target kernel module to be built. The kernel source code information includes the source code list of the target kernel module and the dependencies between the target kernel module and its dependent objects. The build environment information includes the kernel build path of the target kernel module and the compilation context information. Step S120 generates kernel build intermediate data that conforms to the kernel module build specification based on the source code list and dependencies. Step S130 associates the compilation context information with the index target associated with the source code list to generate compilation metadata for code indexing. Step S140 calls the kernel module build system to perform compilation operations for the target kernel module based on the kernel build intermediate data and kernel build path to build the target kernel module. Step S150, during the compilation operation, the compilation metadata is synchronously exported based on the index target for code parsing and indexing by the integrated development environment.

[0207] Storage unit 820 may include readable media in the form of volatile storage units, such as random access memory (RAM) 821 and / or cache memory (Cache) 822, and may further include read-only memory (ROM) 823.

[0208] The storage unit 820 may also include a program / utility 824 having a set (at least one) of program modules 825, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0209] Bus 830 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0210] Electronic device 800 can also communicate with one or more external devices 870 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 800, and / or with any device that enables electronic device 800 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 850. Furthermore, electronic device 800 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 860. As shown, network adapter 860 communicates with other modules of electronic device 800 via bus 830. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 800, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0211] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0212] In exemplary embodiments of this disclosure, a computer-readable storage medium is also provided, on which a program product capable of implementing the methods described above is stored. In some possible embodiments, various aspects of this disclosure may also be implemented as a program product including program code that, when the program product is run on a terminal device, causes the terminal device to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure.

[0213] refer to Figure 9 As shown, a program product 900 for implementing the above-described kernel module construction method according to embodiments of the present disclosure is described. This product may be a portable compact disc read-only memory (CD-ROM) and includes program code, and may run on a terminal device, such as a personal computer. However, the program product of the present disclosure is not limited thereto. In this document, a readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0214] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0215] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0216] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0217] Program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0218] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of this disclosure and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0219] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0220] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This specification is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. It is understood that the specification and embodiments are to be considered exemplary only and are intended to illustrate the true scope and technical concepts of this disclosure.

[0221] It should be understood that this disclosure 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.

Claims

1. A method for constructing a kernel module, characterized in that, include: Obtain the kernel source code information and build environment information corresponding to the target kernel module to be built. The kernel source code information includes the source code list of the target kernel module and the dependencies between the target kernel module and its dependent objects. The build environment information includes the kernel build path of the target kernel module and the compilation context information. Based on the source code list and the dependencies, generate intermediate kernel build data that conforms to the kernel module build specifications; The compilation context information is associated with the index target associated with the source code list to generate compilation metadata for code indexing; Based on the kernel build intermediate data and the kernel build path, the kernel module build system is invoked to perform a compilation operation for the target kernel module, thereby building the target kernel module; as well as During the compilation process, the compilation metadata is exported synchronously based on the index target for code parsing and indexing by the integrated development environment.

2. The method according to claim 1, characterized in that, The kernel build intermediate data includes intermediate build files; the step of generating kernel build intermediate data conforming to the kernel module build specification based on the source code list and the dependencies includes: Based on the source code list and the dependencies, the module composition relationship corresponding to the target kernel module is determined. The module composition relationship is used to characterize the correspondence between the target kernel module and the source files involved in the compilation. According to the syntax form that the kernel module building system can recognize, the module composition relationship is written into the intermediate build file to obtain the kernel build intermediate data that conforms to the kernel module building specification.

3. The method according to claim 2, characterized in that, The step of determining the module composition relationship corresponding to the target kernel module based on the source code list and the dependencies includes: Generate module target definition information based on the source code list; Generate target file mapping relationships based on each source file in the source code list; Generate dependency target declaration information based on the dependencies; Based on the module target definition information, the target file mapping relationship, and the dependency target declaration information, the module composition relationship corresponding to the target kernel module is determined.

4. The method according to claim 1, characterized in that, Before invoking the kernel module build system to perform the compilation operation for the target kernel module based on the kernel build intermediate data and the kernel build path, the method further includes: Based on the source code list and the dependencies, construct an entity build target for performing the compilation operation; The kernel build intermediate data is associated with the entity build target, so as to trigger the kernel module build system to execute the compilation operation through the entity build target.

5. The method according to claim 1, characterized in that, The index target includes a virtual index target; before associating the compilation context information with the index target associated with the source code list to generate compilation metadata for code indexing, the method further includes: Create a build target for the object type, and set the build target for the object type not to participate in the default build process; The source code list is associated with the construction target of the object type to obtain the virtual index target.

6. The method according to claim 1, characterized in that, The compilation context information includes the kernel header file path and kernel compilation macro definition parameters; The step of associating the compilation context information with the index target associated with the source code list to generate compilation metadata for code indexing includes: Set the kernel header file path to the header file search path of the index target; Add the kernel compilation macro definition parameters and the preset kernel identifier macro to the compilation parameters of the index target; Based on the header file search path and the compilation parameters, generate compilation metadata for code indexing.

7. The method according to claim 1, characterized in that, The step of invoking the kernel module build system to perform a compilation operation for the target kernel module based on the kernel build intermediate data and the kernel build path, and building the target kernel module, includes: In response to a compilation instruction used to invoke the kernel module build system, the kernel module build system is triggered to read the kernel build intermediate data and perform a compilation operation for the target kernel module; The compilation instructions carry the kernel build path and the intermediate build file path corresponding to the kernel build intermediate data.

8. The method according to claim 1, characterized in that, The step of performing the compilation operation for the target kernel module and constructing the target kernel module includes: Based on the kernel, intermediate data is constructed, and each source file in the source code list is compiled to generate intermediate target files; Based on the intermediate target file, a linking process is performed to generate the kernel module target file corresponding to the target kernel module; Based on the kernel module target file, the target kernel module is constructed.

9. The method according to claim 1, characterized in that, The compiled metadata includes structured compiled metadata files; During the compilation operation, the compilation metadata is synchronously exported based on the index target, including: During the compilation operation, the compilation commands and compilation parameters corresponding to the index target are recorded; Construct a compilation database structure based on the compilation command and the compilation parameters; Based on the compiled database structure, generate and export the structured compiled metadata file; The structured compilation metadata file is used to provide the header file path, macro definition parameters, and compilation options corresponding to the source file to support code parsing, jumping, and auto-completion functions.

10. The method according to claim 1, characterized in that, The step of obtaining the build environment information corresponding to the target kernel module to be built includes: Obtain the processor architecture information of the runtime environment corresponding to the target kernel module; The construction architecture parameters of the target kernel module are determined based on the processor architecture information; Based on the aforementioned architecture parameters, the kernel build path is searched according to a preset search path or a user-specified path; and The configuration files in the kernel build path are parsed to extract the compilation context information.

11. The method according to claim 10, characterized in that, The compilation context information includes the kernel header file path and kernel compilation macro definition parameters, and the configuration file includes an automatic configuration file; The process of parsing the configuration files in the kernel build path and extracting the compilation context information includes: Parse the autoconfiguration file in the kernel build path to obtain the configuration macros related to the target kernel module; The configuration macros are converted into a set of macro definition parameters recognizable by the kernel module build system, resulting in the kernel compilation macro definition parameters; and The kernel header file path is determined based on the kernel build path.

12. A kernel module construction apparatus, characterized in that, include: The kernel environment detection module is used to obtain the kernel source code information and build environment information corresponding to the target kernel module to be built. The kernel source code information includes the source code list of the target kernel module and the dependencies between the target kernel module and its dependent objects. The build environment information includes the kernel build path of the target kernel module and the compilation context information. The intermediate file generation module is used to generate kernel build intermediate data that conforms to the kernel module build specification based on the source code list and the dependencies. An index metadata generation module is used to associate the compilation context information with the index target associated with the source code list and generate compilation metadata for code indexing. The compilation and execution module is used to call the kernel module construction system to perform compilation operations for the target kernel module based on the kernel construction intermediate data and the kernel construction path, and to build the target kernel module; The metadata export module is used to synchronously export the compilation metadata based on the index target during the compilation operation, so that the integrated development environment can perform code parsing and indexing.

13. An electronic device, characterized in that, include: processor; as well as A memory storing computer-readable instructions that, when executed by the processor, implement the method for constructing a kernel module as described in any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the method for constructing a kernel module as described in any one of claims 1 to 11.

Images