Kernel module compiling method and computer device

Abstract

The embodiment of the application provides a kind of compiling method and computer equipment of kernel module, the method includes: configuring kernel module configuration file in compiling environment, the kernel module configuration file includes the compiling script parameter for first chip platform;Define cross-platform compiling interface, in the case where it is determined that the first chip platform is target chip platform based on compiling script parameter, the cross-platform processing module is called by cross-platform compiling interface, target compiling interface adapted to target chip platform is determined, target chip platform is the chip platform adapted to compiling environment, and the cross-platform processing module is used to process the conversion process of cross-platform compiling interface to target compiling interface;Calling target compiling interface carries out the compilation of kernel module.Therefore, the dependency between modules can be effectively reduced, and development cost and maintenance cost are reduced.

Description

Technical Field

[0001] This application relates to the field of software engineering, specifically to a method for compiling a kernel module and a computer device. Background Technology

[0002] In software development, dependencies between modules often increase the complexity of the software system. Furthermore, different modules may be developed by different software vendors, creating coupling between them and making software upgrades, maintenance, and expansion increasingly difficult. Currently, in the development of systems such as Android, there is a compilation method based on the Android Driver Development Kit (DDK), which can reduce dependencies between modules, thereby improving system maintainability and scalability.

[0003] However, since the Android system may support different chip manufacturers, and different chip manufacturers will use different kernel modules and compilation rules when compiling based on the Android DDK, downstream original equipment manufacturers (OEMs) need to adapt according to the compilation rules of different chip manufacturers, which results in relatively high development and maintenance costs. Summary of the Invention

[0004] This application provides a method for compiling kernel modules and a computer device that can effectively reduce dependencies between modules and reduce development and maintenance costs.

[0005] In a first aspect, this application provides a method for compiling a kernel module, the method comprising: configuring a kernel module configuration file in a compilation environment, the kernel module configuration file including compilation script parameters for a first chip platform; defining a cross-platform compilation interface; when the first chip platform is determined to be a target chip platform based on the compilation script parameters, calling a cross-platform processing module through the cross-platform compilation interface to determine a target compilation interface adapted to the target chip platform, the target chip platform being a chip platform adapted to the compilation environment, the cross-platform processing module being used to handle the conversion process from the cross-platform compilation interface to the target compilation interface; and calling the target compilation interface to compile the kernel module.

[0006] This application aims to isolate dependencies between kernel modules and reduce module coupling by normalizing compilation rules for different chip manufacturers, forming a unified compilation method. First, the computer device (or server) can configure or define files and scripts in the current compilation environment. These files include compilation script parameters for the first chip platform (e.g., rule configurations). Then, when the first chip platform is the target chip platform, a cross-platform processing module is called through a defined cross-platform compilation interface to determine the appropriate target compilation interface. The target compilation interface is then called for compilation. This cross-platform processing module can convert the cross-platform compilation interface to the target compilation interface based on the kernel module configuration file, thereby isolating dependencies between modules through interface conversion.

[0007] In conjunction with the first aspect, in some implementations of the first aspect, when the first chip platform is determined to be the target chip platform based on the compilation script parameters, the above method further includes: selecting the configuration file corresponding to the target chip platform according to the compilation script parameters, and merging the configuration files according to preset inheritance rules.

[0008] Since computer devices may have configuration files corresponding to different chip platforms, and the compilation and execution are for the target chip platform, it is necessary to first select the configuration file corresponding to the target chip platform based on the compilation script parameters. This configuration file includes the configuration parameters corresponding to the target chip platform for the corresponding compilation operation. Furthermore, because the kernel module configuration files corresponding to the chip platform may contain different configurations with certain inheritance relationships—for example, inheritance relationships based on different chip platforms—the computer device can merge the inheritance relationships in the configuration files according to preset inheritance rules to generate a single, unified configuration file.

[0009] Here, it can be understood that the compiler script parameters configured above indicate the chip platform to be compiled. If the first chip platform corresponding to the compiler script parameters is not the target chip platform for which the compilation is currently running, it indicates that there may be errors in the compiler script parameters or the compilation environment, and the computer device can skip the subsequent process. If the first chip platform corresponding to the compiler script parameters is the target chip platform for which the compilation is currently running, it means that the compiler script parameters are suitable for the current target chip platform, and the subsequent compilation work can proceed. This ensures the normal progress of the compilation process.

[0010] In conjunction with the first aspect, in some implementations of the first aspect, the aforementioned preset inheritance rules include configuration inheritance according to a preset arrangement order, with the configuration in the later position inheriting the configuration in the earlier position.

[0011] The preset inheritance rules can be executed according to a preset order. For example, if there are five configurations arranged in the order 1, 2, 3, 4, and 5, then configuration 2 can inherit from configuration 1, configuration 3 can inherit from configurations 1 and 2, configuration 4 can inherit from configurations 1, 2, and 3, and configuration 5 can inherit from configurations 1, 2, 3, and 4. This allows kernel module configuration files to be merged according to the inheritance rules, reducing redundancy in some configurations.

[0012] In conjunction with the first aspect, in some implementations of the first aspect, the above-mentioned method of calling the cross-platform processing module through the cross-platform compilation interface to determine the target compilation interface adapted to the target chip platform includes: calling the cross-platform processing module through the cross-platform compilation interface to determine the target compilation interface adapted to the target chip platform according to the configuration parameters in the configuration file.

[0013] Since the target chip platform has its own compilation rules, the computer device can determine which compilation interface to call based on the configuration parameters corresponding to the target chip platform, that is, the configuration parameters in the above-mentioned merged configuration file.

[0014] In some implementations, the aforementioned kernel module is a module developed based on the Android Driver Development Kit (DDK), and the applicable system is the Android system. The corresponding target compilation interface may include the Android DDK interface or the target chip platform DDK interface. In this case, the computer device can determine whether it needs to call the Android DDK interface based on the configuration parameters in the configuration file. If the Android DDK interface needs to be called, it will be called to compile. If the Android DDK interface does not need to be called, the target chip platform DDK interface will be called directly to compile.

[0015] In conjunction with the first aspect, in some implementations of the first aspect, when the first chip platform is determined to be the target chip platform based on the configuration file, the method further includes: calling the cross-platform processing module to add the dependency relationships and interface parameters corresponding to the target chip platform.

[0016] During compilation on the target chip platform, kernel modules within that platform may have dependencies on each other or other modules, such as file path dependencies or image dependencies. These dependencies can be recorded in the target chip platform's configuration file. The computer device then needs to call the cross-platform processing module to supplement the configuration with these dependencies to ensure successful compilation. Furthermore, since the compilation rules defined by the OEM differ from those of the target chip platform, the cross-platform compilation interface must subsequently call the target chip platform's interfaces (such as DDK interfaces) to successfully convert the cross-platform compilation interface to the target compilation interface.

[0017] In conjunction with the first aspect, in some implementations of the first aspect, the above-mentioned call to the target compilation interface to compile the kernel module includes: compiling the kernel module based on the basic kernel module of the system to which the compilation is applicable, the compilation environment corresponding to the target chip platform, the dependencies and interface parameters, and the kernel module.

[0018] It's understandable that after completing the conversion from the cross-platform compilation interface to the target compilation interface, the computer device can compile in the current compilation environment. The compiled output should be the combination of the basic kernel module of the applicable system, the compilation environment corresponding to the target chip platform, dependencies and interface parameters, and the kernel module. For example, in the Android system environment, the kernel module can include the original equipment manufacturer (OEM) module. The combined result would be Android kernel ACK + chip manufacturer's compilation environment + chip manufacturer's module + OEM module. This shows that regardless of which chip manufacturer's chip platform is chosen, a common set of OEM modules is used. That is, for OEM manufacturers, developing one set of modules and corresponding interfaces is sufficient to achieve adaptation to kernel modules from different chip manufacturers, resulting in relatively low development and maintenance costs.

[0019] In conjunction with the first aspect, in some implementations of the first aspect, when multiple kernel module configuration files for different chip platforms are configured in the compilation environment, the multiple different kernel module configuration files are stored in the same directory structure.

[0020] The aforementioned kernel module compilation method is applicable to different chip platforms. Therefore, the kernel module configuration files for different chip platforms need to be configured in the compilation environment. In this implementation, the kernel module configuration files for different chip platforms can all be stored in the xxx / configs directory, enabling the sharing of module repository code across different chip platforms. When a compilation operation is triggered, the computer device can complete the compilation process based on the configured parameters and the aforementioned compilation rules. Thus, in this application, only the aforementioned definition file script, parameter configuration, and compilation configuration are needed to compile the kernel module, eliminating the need to develop different compilation rules for different chip manufacturers and reducing development costs.

[0021] In conjunction with the first aspect, in some implementations of the first aspect, the kernel module configuration file includes at least one of the following: the configs directory module configuration file, the mk Android compilation script, the bazel module compilation script, the Kconfig kernel configuration script, and the C source code.

[0022] For example, the configuration files in the configs directory can include rule configurations for different chip manufacturers, the mk Android build script can be Android.mk, the bazel module build script can be BUILD.bazel, and the C source code can be demo.c. These defined files or scripts together constitute the kernel module configuration files mentioned above.

[0023] In conjunction with the first aspect, in some implementations of the first aspect, the above method further includes: when the kernel module is deployed on an independent chip platform and different chip platforms correspond to different kernel modules, different chip platforms correspond to different source code and different compilation scripts; when the kernel module is deployed on different chip platforms and the chip platforms have dependent absolute paths, different chip platforms correspond to the same source code and different compilation scripts; when the kernel module is deployed on different chip platforms and the chip platforms do not have dependent absolute paths, different chip platforms correspond to the same source code and the same compilation script.

[0024] In this implementation, this application also considers the requirements of the chip platform to be deployed, and formulates corresponding compilation rules for different chip platforms. For example, when deployed on a single chip platform, meaning the compilation rules are applicable only to one chip platform, the compilation rules can correspond to a single kernel module file, and the code and compilation scripts in the module are independent and not reused. As another example, when deployed on a non-independent chip platform, meaning the compilation rules are applicable to multiple chip platforms, not limited to one, the kernel module file directory and included code can be reused for different chip platforms, but the compilation scripts used during compilation can not be reused. In this case, absolute paths of chip platform dependencies can exist, i.e., a certain dependency relationship is allowed. Yet another example, when deployed on a non-independent chip platform, meaning the compilation rules are applicable to multiple chip platforms, not limited to one, not only the kernel module file directory and included code can be reused, but the compilation scripts used during compilation can also be reused, i.e., the same compilation scripts are used. In this case, absolute paths of chip platform dependencies cannot exist. Therefore, the above implementation method can be adapted to different compilation requirements, further improving adaptability.

[0025] In conjunction with the first aspect, in some implementations of the first aspect, where different chip platforms correspond to different source codes and different compilation scripts, or where different chip platforms correspond to the same source code and different compilation scripts, the above method further includes: configuring the dependency relationships and interface parameters corresponding to the first chip platform in the compilation environment.

[0026] In other words, additional configurations can be made in the computer device's compilation environment to meet different needs. In addition to configuring the configs directory module configuration files, mk Android compilation scripts, bazel module compilation scripts, Kconfig kernel configuration scripts, and C source code as described above, module dependencies, interface parameters, parameter call relationships, and other data can be configured before calling the OEM DDK interface. In this configuration scenario, when the computer device calls the OEM DDK cross-platform processing module, it no longer needs to perform the process of adding and configuring the chip platform's corresponding dependencies and DDK interface parameters. The dependency relationships and interface parameters are directly integrated into the corresponding chip platform DDK interface for compilation, thus meeting specific needs in the development process.

[0027] Secondly, this application provides an apparatus included in a computer device, which has the function of implementing the computer device behavior described in the first aspect and its possible implementations. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the above-described functions. For example, a receiving module or unit, a processing module or unit, etc.

[0028] Thirdly, this application provides a computer device, which includes: one or more processors and a memory;

[0029] The memory is coupled to the one or more processors, and the memory is used to store computer program code, the computer program code including computer instructions, which the one or more processors call to cause the computer device to perform any one of the methods in the first aspect of the technical solution.

[0030] Fourthly, this application provides a chip system applied to a computer device, the chip system including one or more processors, the one or more processors being configured to invoke computer instructions to cause the computer device to perform the methods in the first aspect and any possible implementation thereof.

[0031] Optionally, the chip system also includes a memory, which is connected to the processor via circuitry or wires.

[0032] Alternatively, the chip system may also include a communication interface.

[0033] Fifthly, this application provides a computer-readable storage medium including instructions that, when executed on a computer device, cause the computer device to perform any one of the methods in the first aspect of the technical solution.

[0034] Sixthly, this application provides a computer program product, which includes: computer program code, which, when run on a computer device, causes the computer device to execute any one of the methods in the first aspect of the technical solution. Attached Figure Description

[0035] Figure 1 This is a schematic diagram illustrating an example of OEM module maintenance provided by related technologies;

[0036] Figure 2 This is a schematic diagram illustrating an example of an OEM module maintenance method provided in an embodiment of this application;

[0037] Figure 3 This is a schematic diagram illustrating the calling relationship of various DDK interfaces provided in an embodiment of this application;

[0038] Figure 4 This is a schematic diagram illustrating the configuration results of different parameter files under the configs configuration file provided in an embodiment of this application;

[0039] Figure 5 This is a schematic diagram of the processing procedure of an OEM DDK cross-platform processing module provided in an embodiment of this application;

[0040] Figure 6 This is a schematic diagram of an example kernel module file configuration provided in an embodiment of this application;

[0041] Figure 7 This is a schematic diagram illustrating an example of the dependency relationship between different modules provided in an embodiment of this application;

[0042] Figure 8 This is a schematic diagram illustrating an example of selecting different module processing methods based on different needs, provided by an embodiment of this application.

[0043] Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application;

[0044] Figure 10 This is a schematic diagram of the structure of a server provided in an embodiment of this application. Detailed Implementation

[0045] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0046] Hereinafter, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include one or more of that feature.

[0047] In software development, dependencies between modules often increase the complexity of the software system. Furthermore, different modules may be developed by different software vendors, leading to coupling between them and making software upgrades, maintenance, and expansion increasingly difficult. Currently, Android system development offers several effective module decoupling methods, such as compilation based on the Android DDK, which can reduce dependencies between modules, thereby improving system maintainability and scalability.

[0048] The Android DDK is a toolkit for developing Android kernel modules, designed to simplify the development process. It provides a simpler method for developing kernel modules compatible with the GKI (generic kernel image) kernel, making it well-suited for Android system development. GKI is a customizable kernel image designed to provide general hardware support and minimize kernel size, making it suitable for as many devices and hardware platforms as possible. The Android kernel, on the other hand, is the core of an open-source operating system based on the Linux kernel, primarily responsible for managing system resources and interacting with hardware.

[0049] Generally, the Android kernel mainly includes the following components:

[0050] Process management: Responsible for creating, scheduling, and terminating processes.

[0051] Memory management: Responsible for dynamically allocating and reclaiming memory.

[0052] File system: Used to manage the device's storage.

[0053] Network support: Implements the network protocol stack and provides network communication capabilities.

[0054] Hardware Abstraction Layer (HAL): Enables upper-layer applications to interact with lower-layer hardware devices.

[0055] It is evident that kernel modules play a crucial role in system development, and the Android DDK can provide convenience for kernel module development. For example, the Android DDK can automatically generate Makefiles during use, specifying which files need to be compiled first, which need to be compiled later, and which need to be recompiled. It also supports GKI kernel module definitions and provides reasonable migration steps. In addition, the Android DDK offers toolchain management, resource visibility, and simplified module definition features. It ensures the correct use of the toolchain (such as compilers, linkers, and flags) during the compilation process, ensures the correct visibility of resources provided by the GKI kernel (such as header files and Makefiles), and allows the definition of various kernel modules in the same location, avoiding scattered definition locations. Based on this, developers are focusing on migrating the Android kernel build process to... The system utilizes the Bazel build system and the Kleaf framework. It is compiled based on the Kleaf framework and introduces the DDK to build external modules, reducing the coupling between modules, managing and building Android kernel modules more efficiently, and improving the maintainability and scalability of the system.

[0056] Therefore, for electronic devices running the Android system, to meet the current high demands on electronic products—such as industry requirements for longer-term operating system update services, product requirements for supporting major kernel version upgrades, and longer-term software upgrades—chip manufacturers and OEMs need to deeply decouple their software architecture. Consequently, they are focusing on system development based on the Android DDK to provide long-lifecycle maintenance solutions for electronic devices. The currently popular Android common kernel (ACK) specification comes from... Its kernel uses a unified codebase and manages the KMI (kernel module interface) to unify module interfaces. With the introduction of the Android DDK, external kernel modules, such as those from chip manufacturers, are also required to compile using the DDK. Chip manufacturers migrate their self-developed kernel modules' DDK compilation methods according to their own needs. The final compilation result is an Android kernel plus external module DDK compilation.

[0057] However, since the Android system may support different chip manufacturers, and different chip manufacturers will use different kernel modules and compilation rules when compiling based on the Android DDK, downstream OEM manufacturers need to adapt according to the compilation rules of different chip manufacturers, which results in relatively high development and maintenance costs.

[0058] For example, such as Figure 1 As shown, the Android kernel ACK can be generated by... Based on the Linux open-source code and its own rules, chip manufacturers can develop and package the Android kernel's existing functions and their own additional functions, creating dependencies (deps) between the chip and the Android kernel ACK. For OEMs, however, they need to learn and formulate different compilation rules based on the DDK compilation methods and basic package compilation environments provided by different chip manufacturers. For example... Figure 1 As shown, suppose there are two chip manufacturers, Vendor1 and Vendor2, each with different kernel modules. These kernel modules can depend on base modules. The OEM manufacturer also needs to maintain two sets of modules: OEM Module 1 and OEM Module 2. Different modules require different interfaces for use, and development and maintenance necessitate intrusive modifications to configuration files and Makefiles for each module. It's conceivable that if multiple new chip manufacturers emerge, the OEM manufacturer will need to maintain even more new modules, resulting in high development and maintenance costs.

[0059] Considering the aforementioned issues, from the perspective of OEM manufacturers, maintaining a single set of modules for different chip manufacturers' chip platforms can significantly reduce development and maintenance costs. Furthermore, independent module decoupling facilitates kernel version upgrades. Therefore, this application provides a kernel module compilation method that normalizes the compilation rules for different chip manufacturers, forming a set of adapted compilation methods (or rules). This achieves cross-chip platform module decoupling, effectively reducing dependencies between modules, lowering development and maintenance costs, and consequently improving the maintainability and scalability of the software system. For example, after module decoupling, each module can be upgraded or replaced independently. For instance, in the event of a kernel structure change, only the kernel image needs to be upgraded; in the event of a chip manufacturer's module change, only the chip manufacturer's module needs to be upgraded; and OEM manufacturer modules support independent upgrades.

[0060] It is understood that the kernel module compilation method provided in this application embodiment can be applied to the compilation stage of software systems on electronic devices, especially for the development and compilation process of Android systems. Electronic devices that install Android systems can include, but are not limited to, mobile phones, tablets, wearable devices, in-vehicle devices, augmented reality (AR) / virtual reality (VR) devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, personal digital assistants (PDAs), etc. The device that performs the compilation operation during the compilation stage of the software system can be another computer device or server. This application embodiment does not impose any restrictions on the specific type of electronic device.

[0061] The following describes the compilation method of the kernel module provided in the embodiments of this application, such as... Figure 2 As shown, when OEM manufacturers learn and formulate a set of compilation rules based on the DDK compilation methods of different chip manufacturers, they can also provide a corresponding module and interface. Through this module, the dependencies (deps) on the kernel modules of different chip manufacturers can be isolated, reducing the coupling impact of the kernel modules of different chip manufacturers.

[0062] First, in the compilation environment of a computer device (or server; for ease of description, a computer device will be used as an example), the OEM module needs to define some files and scripts for the current compilation configuration, such as, but not limited to, module configuration files in the `configs` directory, the `mk` Android compilation script, the `bazel` module compilation script, the `Kconfig` kernel configuration script, and C source code. For example, the module configuration file in the `configs` directory can include rule configurations (including configuration parameters) for different chip manufacturers, the `mk` Android compilation script can be `Andriod.mk`, the `bazel` module compilation script can be `BUILD.bazel`, and the C source code can be `demo.c`. In some implementations, the configuration files and scripts can be structured as follows, where each field is defined:

[0063] load(" / / build / kernel / kleaf:OEM_modules.bzl", "define_OEM_modules")

[0064] define_OEM_modules(

[0065] #out is name.ko

[0066] name = "demo",

[0067] srcs = ["OEM_demo.c"],

[0068] visibility=[" / / visibility: public"],

[0069] kconfig="kconfig" )

[0071] Then, on the computer device, the OEM module also needs to define a normalized interface. This interface can be a compilation interface based on the Android DDK (also known as a cross-platform compilation interface), such as an OEM DDK interface. This interface can call the chip platform DDK interface and the Android DDK interface by invoking the cross-platform processing module. For example, the cross-platform processing module here can be an OEM DDK cross-platform processing module. In some implementations, the calling relationship of the various DDK interfaces can be as follows: Figure 3 As shown, the OEM DDK interface calls the OEM DDK cross-platform processing module. Through this module's processing, it can determine whether a further call to the chip platform's DDK interface or the Android DDK interface is needed. Furthermore, if a call to the chip platform's DDK interface is required, it determines which chip manufacturer's DDK interface to invoke. For example, assuming there are two chip manufacturers, Vendor1 and Vendor2, with corresponding DDK interfaces Vendor1 and Vendor2 respectively, the OEM DDK cross-platform processing module, after interface conversion, can determine whether to call the Vendor1 DDK interface, the Vendor2 DDK interface, or directly the Android DDK interface.

[0072] Based on this, the OEM DDK cross-platform processing module can convert the OEM DDK interface to DDK interfaces of different chip platforms or Android DDK interfaces, isolating the OEM module from the kernel modules of different chip manufacturers. After completing the DDK interface conversion, the OEM manufacturer's compilation environment and module result are Android kernel ACK + chip manufacturer's compilation environment + chip manufacturer's module + OEM module. For example, if the OEM manufacturer wants to develop a system on chip manufacturer A's chip platform, the compilation result is Android kernel ACK + chip manufacturer A's compilation environment + chip manufacturer A's module + OEM module. If the OEM manufacturer wants to develop a system on chip manufacturer B's chip platform, the compilation result is Android kernel ACK + chip manufacturer B's compilation environment + chip manufacturer B's module + OEM module. It can be seen that regardless of which chip manufacturer chooses, a common set of OEM modules is used. That is, for the OEM manufacturer, developing one set of modules and corresponding interfaces can achieve adaptation to kernel modules of different chip manufacturers, resulting in relatively low development and maintenance costs.

[0073] As described above, the OEM module has completed the compilation rules. To deploy it on a chip platform, simply configure the chip platform's parameter file (e.g., xxx.config) in the module configuration file (also referred to as the configs configuration file) in the aforementioned configs directory. For example, the configuration results of different xxx.config parameter files under the configs configuration file can be found in [link to configuration file]. Figure 4 This configuration allows OEM modules to adapt to different chip platforms. In some implementations, parameter files for different chip platforms can be stored in the xxx / configs directory, enabling different chip platforms to share module repository code. When a compilation operation is triggered, the computer device can complete the compilation process based on the configured parameters and the aforementioned compilation rules. Therefore, in this embodiment, only the aforementioned definition file script, parameter configuration, and compilation configuration are needed to compile the OEM module. Compared to related technologies that use different compilation rules for different chip manufacturers, this eliminates the need for intrusive modifications to configuration files, Makefiles, etc.

[0074] It is understandable that in the above implementation, the OEM DDK cross-platform processing module plays the role of DDK interface conversion. In some embodiments, the processing procedure of the OEM DDK cross-platform processing module can be as follows: Figure 5 As shown, the specific steps include:

[0075] S101 reads the compiler script parameters during the compilation phase.

[0076] It is understandable that the compilation script has already been configured when the compilation begins, so the OEM DDK cross-platform processing module can obtain the compilation script parameters contained therein.

[0077] S102: Based on the compiler script parameters, determine whether the chip platform corresponding to the compiler script parameters is the target chip platform for the current compilation. If it is the target chip platform, execute S103; otherwise, end the process.

[0078] Specifically, the compiler script parameters indicate the chip platform to be compiled. For example, the compiler script parameters may include platform information. If the chip platform corresponding to the compiler script parameters is not the target chip platform for the current compilation, it indicates that there may be an error in the compiler script parameters or the compilation environment. In this case, the OEMDDK cross-platform processing module can terminate the process. For instance, suppose the chip platform determined by the compiler script parameters is Q1, but the chip platform for the current compilation is Q2. The two do not match, so the compilation is unlikely to succeed, and further processing is unnecessary.

[0079] Optionally, an error message can be output to the user after the process ends, allowing the user to perform operations such as modifying the compilation script.

[0080] If the chip platform corresponding to the compiler script parameters is the target chip platform on which the current compilation is running, it means that the compiler script parameters are applicable to the current target chip platform. In this case, the OEM DDK cross-platform processing module can proceed with subsequent steps to convert the DDK interface.

[0081] S103 selects the configs configuration file corresponding to the target chip platform according to the compilation script parameters and merges the configs configuration files according to the preset inheritance rules.

[0082] Since computer devices may have different configuration files for different chip platforms, and the compilation and execution are for the target chip platform, the OEM DDK cross-platform processing module needs to first select the configuration file corresponding to the target chip platform based on the compilation script parameters. The configuration file contains the configuration parameters for the target chip platform to perform the corresponding compilation operation. Furthermore, because these configuration files may have different configurations with inheritance relationships (which can be based on different chip platforms), when the OEM DDK cross-platform processing module is called through the OEM DDK interface for compilation, the OEM DDK cross-platform processing module can merge the inheritance relationships in the configuration files according to preset inheritance rules, for example, merging them into a single configuration file.

[0083] In some implementations, the preset inheritance rule can be to inherit configurations according to a preset order, with later configurations inheriting from earlier ones. For example, suppose there are five configurations arranged as follows: 1. "perf": overseas performance configuration; 2. "cnperf": domestic performance configuration; 3. "consolidate": non-performance version configuration; 4. "factory": burn-in version; 5. "double85": double 85 test version. Then, configuration 2 can inherit from configuration 1, configuration 3 can inherit from configurations 1 and 2, configuration 4 can inherit from configurations 1, 2, and 3, and configuration 5 can inherit from configurations 1, 2, 3, and 4. Through this inheritance rule, the OEM DDK cross-platform processing module can merge configuration files.

[0084] For example, the OEM DDK cross-platform processing module can merge the configs configuration file using srcs.append("configs / "+t+"_"+la_variant+".config").

[0085] S104 adds the dependency relationships and DDK interface parameters corresponding to the target chip platform.

[0086] Typically, during compilation on a target chip platform, kernel modules within that platform may have dependencies on each other or other modules, such as file path dependencies or image dependencies. These dependencies can be recorded in the target chip platform's configuration file. Therefore, the OEM DDK cross-platform processing module needs to supplement the configuration with these target chip platform dependencies to ensure smooth compilation. Furthermore, since the compilation rules defined by the OEM manufacturer differ from those of the target chip platform, the OEM DDK cross-platform processing module also needs to complete the corresponding DDK interface parameters for the target chip platform to ensure successful calls from the OEM DDK interface to the target chip platform's DDK interface. This completes the conversion between the OEM DDK interface and the DDK interface for different chip platforms.

[0087] For example, if the target chip platform is the first platform, the corresponding dependency relationship can be kernel_build = " / / xxx:()_base_kernel".format(tv).

[0088] S105: Based on the configuration parameters corresponding to the target chip platform, determine whether it is necessary to call the Android DDK interface. If it is necessary to call the Android DDK interface, execute S106; otherwise, execute S107.

[0089] S106 uses the Android DDK interface for compilation.

[0090] S107 calls the target chip platform's DDK interface for compilation.

[0091] Since the target chip platform has its own compilation rules and its own encapsulation results of the Android kernel, the OEM DDK cross-platform processing module can determine whether to call the Android DDK interface based on the configuration parameters corresponding to the target chip platform, that is, based on the encapsulation results of the Android kernel of the target chip platform. If the Android DDK interface needs to be called, the Android DDK interface is called for compilation; if the Android DDK interface does not need to be called, the target chip platform DDK interface is called directly for compilation.

[0092] Therefore, through the above processing of the OEM DDK cross-platform processing module, the conversion of the OEM DDK interface to the DDK interface of different chip platforms or the Android DDK interface can be realized. Based on the chip platform dependency relationship, isolation configuration is performed, which isolates the OEM module's dependency on the kernel modules of different chip manufacturers, and also isolates the differences between different chip platforms, thereby reducing development costs and subsequent maintenance costs.

[0093] In other scenarios, embodiments of this application may also consider that the actual development process may have special requirements for the chip platform to be deployed. In such cases, corresponding compilation rules can be formulated for modules of different chip platforms, and different module adaptation methods can be configured on computer devices. The modules may consist of code (such as .c file code) and compilation scripts.

[0094] The first requirement applies when deployed on a single, independent chip platform. This means the compilation rules are only applicable to one platform, and in this case, each set of rules corresponds to a separate kernel module file (.ko file). Here, .ko is a module file, also the dynamically linked file used by the Linux 2.6 kernel. This means that the kernel module file is independent in terms of storage directory for different chip platforms; the directory name can be used to distinguish the module stored on each platform. Furthermore, the code and compilation scripts within the module are independent and not reused. Also, because it's an independent kernel module file, it can contain absolute paths to chip platform dependencies, allowing for certain dependency relationships.

[0095] The second requirement applies to deployments on non-independent chip platforms. This means the compilation rules can be applied to multiple chip platforms, not just one. In this case, the kernel module file directory and included code can be reused across different chip platforms, but the compilation scripts used during compilation can be different; that is, independent compilation scripts with different configurations are used. For example, such as... Figure 6 As shown, taking a kernel module file as an example, it contains a .c file and bzl files corresponding to multiple chip platforms (two in the diagram). These bzl files (i.e., Bazel scripts) can be used to define the compilation rules for source files, the execution methods for test cases, and the overall build process of the project. It can be understood that in this scenario, because the compilation scripts are independent, absolute paths to chip platform dependencies can exist.

[0096] The third requirement applies to deployments on non-independent chip platforms. This means the compilation rules can be applied to multiple chip platforms, not just one. Unlike the second requirement, this set of compilation rules allows for reuse not only of the kernel module file directory and its contained code, but also of the compilation scripts used during compilation. In this case, chip platform macros can be defined using the Kconfig kernel configuration script to ensure compatibility across different chip platforms. It's understandable that, because the compilation scripts are reusable in this scenario, the module cannot contain absolute paths to chip platforms. If chip platform dependencies exist, refer to the OEM DDK cross-platform processing module configuration process in S103 above to isolate these dependencies.

[0097] Furthermore, given the existing kernel module files corresponding to three different requirements, there can be certain dependencies between different modules. For example, such as... Figure 7 As shown, assuming the first requirement corresponds to files 1.ko and 1'.ko, the second requirement corresponds to files 2.ko and 2'.ko, and the third requirement corresponds to files 3.ko and 3'.ko, then 1.ko can directly depend on 1'.ko, 2'.ko, and 3'.ko, and 2.ko can also directly depend on 1'.ko, 2'.ko, and 3'.ko, while 3.ko cannot directly depend on 1'.ko, 2'.ko, and 3'.ko. Dependency isolation can be achieved using the OEM DDK cross-platform processing module.

[0098] Therefore, for the three different scenarios mentioned above, computer devices can select different module processing methods based on different needs. The selection methods can be found in [reference needed]. Figure 8First, determine if the current compilation is applicable to a single chip platform. If it is, the compilation rules corresponding to the first requirement mentioned above can be used. If it is not applicable to a single chip platform, determine if there is a dependency on the chip platform. If there is a dependency, the compilation rules corresponding to the second requirement mentioned above can be used; if there is no dependency, the compilation rules corresponding to the third requirement mentioned above can be used. After selecting different module processing methods, additional configuration is required in the computer device's compilation environment. That is, in addition to configuring the configs directory module configuration files, mk Android compilation scripts, bazel module compilation scripts, Kconfig kernel configuration scripts, and C source code as described in the above embodiments, it is also necessary to configure the module's dependencies, interface parameters, parameter call relationships, and other data before calling the OEM DDK interface (it can be seen that these are in the above...). Figure 5 In this embodiment, no configuration is required; it can be completed using the OEM DDK cross-platform processing module.

[0099] Therefore, when compilation begins, the following process can be performed by calling the OEM DDK cross-platform processing module through the OEM DDK interface: First, the configuration parameters of the additional configuration mentioned above in the configuration file are used to determine the current compilation corresponding to... Figure 7 If it's a dependency corresponding to the first or second requirement, since it can directly depend on other kernel module files, the subsequent OEM DDK cross-platform processing module doesn't need to perform the process of adding configuration dependencies for the corresponding chip platform. It can directly permeate the dependency relationship and the added DDK interface parameters into the corresponding chip platform DDK interface for compilation. If it's a dependency corresponding to the third requirement, since it cannot directly depend on other kernel module files, the OEM DDK cross-platform processing module can proceed as described above. Figure 5 The implementation steps involve adding the dependencies and DDK interface parameters corresponding to the configuration chip platform, and then calling the corresponding DDK interface for compilation. Therefore, in this embodiment, the computer device can select the appropriate processing method based on the actual needs of the specific scenario, further increasing the adaptability of the above-mentioned kernel module compilation method.

[0100] As described in the above embodiments, the compilation method of the kernel module can be executed by a computer device or server. Therefore, in order to implement this compilation method, the computer device or server needs to possess the following... Figure 9 The structure shown. See also Figure 9 For example, a computer device may include a processor 210, a memory 220, and a communication module 230.

[0101] The processor 210 may include one or more processing units, and the memory 220 is used to store program code and data. In this embodiment, the processor 210 can execute computer execution instructions stored in the memory 220.

[0102] The communication module 230 can be used for communication between various internal modules of a computer device, or for communication between the computer device and other devices. For example, if the computer device communicates with other devices via a wired connection, the communication module 230 may include an interface, such as a Universal Serial Bus (USB) interface. The USB interface can be an interface conforming to the USB standard specification, specifically a Mini USB interface, a Micro USB interface, a USB Type-C interface, etc. The USB interface can be used to connect a charger to charge the computer device, to transfer data between the computer device and other devices, and to connect headphones for audio playback, etc.

[0103] Alternatively, the communication module 230 may include audio devices, radio frequency circuits, Bluetooth chips, wireless fidelity (Wi-Fi) chips, near-field communication (NFC) modules, etc., which can enable interaction between computer devices and other devices in a variety of different ways.

[0104] In addition, the computer device may also include a display screen 240, which can display images or videos from the human-computer interaction interface. For example, it can display the configured files and scripts mentioned above, and display compilation results.

[0105] Optionally, the computer device may also include peripheral devices 250, such as a mouse, keyboard, speaker, microphone, etc.

[0106] It should be understood that, in addition to Figure 9 In addition to the various components or modules listed, the embodiments of this application do not specifically limit the structure of the computer device. In other embodiments of this application, the computer device may also include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The components illustrated may be implemented in hardware, software, or a combination of software and hardware.

[0107] In other embodiments, the computer device described above may include a definition module, an OEM DDK cross-platform processing module, and a compilation module.

[0108] The definition module is used to configure or define files and scripts, including but not limited to module configuration files in the `configs` directory, `mk` Android compilation scripts, `bazel` module compilation scripts, `Kconfig` kernel configuration scripts, and C source code. The definition module also defines a normalized interface, which can be a compilation interface based on the Android DDK, such as an OEMDDK interface. This interface, by calling the cross-platform processing module, can call the DDK interface of the chip platform or the Android DDK interface. The OEM DDK cross-platform processing module is used to convert the OEM DDK interface to different chip platform DDK interfaces or Android DDK interfaces. The compilation module is used to perform the compilation operation after the interface conversion.

[0109] It is also understood that when a server executes the compilation method of the aforementioned kernel module, it can be a single server or a server cluster; this application embodiment does not impose any limitations on this. For example, Figure 10 This is a schematic diagram of a server structure provided in an embodiment of this application. The server includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage medium. The server's database can be used to store the aforementioned multi-defined files, scripts, and configured data. The server's network interface can be used to communicate with external devices via a network connection.

[0110] The foregoing has detailed examples of the compilation methods for kernel modules provided in the embodiments of this application. It is understood that, in order to implement the above functions, a computer device includes hardware and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in conjunction with the embodiments, but such implementation should not be considered beyond the scope of this application.

[0111] This application embodiment can divide a computer device into functional modules based on the above method example. For example, each function can be divided into its own functional module, such as a detection unit, a processing unit, a display unit, etc., or two or more functions can be integrated into one module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0112] It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0113] The computer device provided in this embodiment is used to execute the compilation method of the above-described kernel module, and thus can achieve the same effect as the above-described implementation method.

[0114] When using integrated units, a computer device may also include a processing module, a storage module, and a communication module. The processing module is used to control and manage the operation of the computer device. The storage module supports the execution of stored program code and data. The communication module supports communication between the computer device and other devices.

[0115] The processing module can be a processor or a controller. It can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a digital signal processor and a microprocessor, etc. The storage module can be a memory. The communication module can specifically be a radio frequency circuit, a Bluetooth chip, a Wi-Fi chip, or other devices that interact with other electronic devices.

[0116] This application also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the processor performs the compilation method of the kernel module of any of the above embodiments. The storage medium may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0117] This application also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement the kernel module compilation method in the above embodiments.

[0118] In this embodiment, the computer device, computer-readable storage medium, computer program product or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0119] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0120] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0121] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for compiling a kernel module, characterized in that, The method includes: Configure the kernel module configuration file in the compilation environment, the kernel module configuration file including compilation script parameters for the first chip platform; A cross-platform compilation interface is defined. When the first chip platform is determined to be the target chip platform based on the compilation script parameters, the cross-platform processing module is called through the cross-platform compilation interface to determine the target compilation interface adapted to the target chip platform. The target chip platform is the chip platform adapted to the compilation environment. The cross-platform processing module is used to process the conversion process from the cross-platform compilation interface to the target compilation interface. The kernel module is compiled by calling the target compilation interface.

2. The method according to claim 1, characterized in that, When the first chip platform is determined to be the target chip platform based on the compilation script parameters, the method further includes: The configuration file corresponding to the target chip platform is selected according to the compilation script parameters, and the configuration file is merged according to the preset inheritance rules.

3. The method according to claim 2, characterized in that, The preset inheritance rules include inheriting configurations according to a preset order, with later configurations inheriting earlier configurations.

4. The method according to claim 2 or 3, characterized in that, The step of calling the cross-platform processing module through the cross-platform compilation interface to determine the target compilation interface adapted to the target chip platform includes: The cross-platform compilation interface is used to call the cross-platform processing module, and the target compilation interface adapted to the target chip platform is determined according to the configuration parameters in the configuration file.

5. The method according to any one of claims 1 to 4, characterized in that, When the first chip platform is determined to be the target chip platform based on the compilation script parameters, the method further includes: The cross-platform processing module is invoked to add and configure the dependencies and interface parameters corresponding to the target chip platform.

6. The method according to claim 5, characterized in that, The process of calling the target compilation interface to compile the kernel module includes: The kernel module is compiled based on the basic kernel module of the system to which the compilation is applicable, the compilation environment corresponding to the target chip platform, the dependencies and interface parameters, and the kernel module itself.

7. The method according to any one of claims 1 to 6, characterized in that, In the case where multiple kernel module configuration files for different chip platforms are configured in the compilation environment, the multiple different kernel module configuration files are stored in the same directory structure.

8. The method according to any one of claims 1 to 7, characterized in that, The kernel module is a module developed based on the Android Driver Development Kit (DDK).

9. The method according to claim 8, characterized in that, The target compilation interface includes the Android DDK interface or the target chip platform DDK interface.

10. The method according to claim 8 or 9, characterized in that, The kernel module configuration file includes at least one of the following: the configs directory module configuration file, the mk Android compilation script, the bazel module compilation script, the Kconfig kernel configuration script, and C source code.

11. The method according to any one of claims 1 to 10, characterized in that, The kernel module includes original equipment manufacturer (OEM) modules.

12. The method according to any one of claims 1 to 11, characterized in that, The method further includes: When the kernel module is deployed on a separate chip platform, and different chip platforms correspond to different kernel modules, different chip platforms correspond to different source code and different compilation scripts; When the kernel module is deployed on different chip platforms and the chip platforms have dependent absolute paths, the different chip platforms correspond to the same source code but different compilation scripts; When the kernel module is deployed on different chip platforms and there is no absolute path that the chip platforms depend on, the different chip platforms correspond to the same source code and the same compilation script.

13. The method according to claim 12, characterized in that, When different chip platforms correspond to different source codes and different compilation scripts, or when different chip platforms correspond to the same source code and different compilation scripts, the method further includes: Configure the dependencies and interface parameters corresponding to the first chip platform in the compilation environment.

14. A computer device, characterized in that, The computer device includes: One or more processors, and memory; The memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the computer device to perform the method as described in any one of claims 1 to 13.

15. A chip system, characterized in that, The chip system is applied to a computer device, the chip system including one or more processors, the one or more processors being used to invoke computer instructions to cause the computer device to perform the method as described in any one of claims 1 to 13.

16. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes instructions that, when executed on a computer device, cause the computer device to perform the method as described in any one of claims 1 to 13.

17. A computer program product, characterized in that, The computer program product includes a computer program that, when run on a computer device, causes the computer device to perform the method as described in any one of claims 1 to 13.

Images