Kconfig-based rust language cargo package system level configuration method and device

Abstract

The application discloses a Rust language Cargo package system-level configuration method and device based on Kconfig, relates to the technical field of computers, and comprises the following steps: defining system-level configuration items and corresponding dependency relations by using a configuration file; inputting a code package file configuration declaration access identifier; receiving a command line parameter analysis file path to obtain a system-level configuration file, extracting enabled configuration items to form an internal mapping table, and converting the internal mapping table into a compilation parameter to perform corresponding conditional compilation containing system-level configuration. By centrally defining system-level configuration, the same global configuration is shared by various code packages, and the problem of system-level concept fragmentation is solved. By accurately identifying the affected code package range through the access identifier, automatically analyzing the command line, reading the configuration and the compilation parameter conversion, forming the conditional compilation parameter and the feature enable parameter, and ensuring that the configuration is simultaneously effective in the compiler and the dependency management, the system-level configuration is flexibly and uniformly managed by using double-layer configuration when facing large projects.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a system-level configuration method and apparatus for the Cargo package in Rust language based on Kconfig. Background Technology

[0002] In recent years, Rust has been increasingly used to develop large-scale system software such as operating system kernels and embedded firmware due to its memory safety features and high performance. To improve the maintainability and scalability of large projects, when writing engineering software in Rust, Cargo's modern package management capabilities can be leveraged for automatic dependency resolution, version management, and parallel compilation. This allows for the decomposition of complex systems into multiple independent crames, resulting in a highly modular design that improves code reusability. Different functional modules can be selectively compiled based on the target platform or application scenario.

[0003] However, when writing large-scale engineering software such as operating systems in Rust, the OS kernel may contain dozens to hundreds of functional modules, and the configuration flexibility requirements are high, necessitating dynamic tailoring of functions based on hardware platforms and application scenarios. While the Linux kernel has begun to support Rust code and utilizes Kconfig for configuration, its build system and Cargo package management ecosystem remain isolated. Even if conditional compilation is implemented using the features mechanism provided by Rust's Cargo tool, a system-level concept is still forced to be fragmented into configurations of multiple Crates' individual features within Cargo, leading to architectural limitations such as the need to configure massive amounts of features and dependency declarations when features change, resulting in explosive configuration management complexity, dispersed configuration control, and an inability to accurately express complex logical constraints. Summary of the Invention

[0004] This invention provides a system-level configuration method and apparatus for the Cargo package in Rust based on Kconfig, in order to solve the technical problem that fragmented system-level conceptual configuration in large projects leads to cumbersome configuration and an inability to accurately express configuration logic.

[0005] In a first aspect, embodiments of the present invention provide a system-level configuration method for the Rust language Cargo package based on Kconfig, including: S101, in the Cargo workspace of the Rust project, uses the Kconfig configuration file to define the system-level configuration items and corresponding dependencies of all code packages Crate, and generates a system-level configuration file; S102, using the preset configuration build tool, configure the preset access identifier in the Cargo.toml file of the code package to declare that the code package is connected to the Kconfig configuration; S103 receives the command-line parameters for starting the build input from the user and parses them using a preset configuration build tool. It identifies the system-level configuration file path specified by the configuration path parameter to obtain the system-level configuration file, extracts the enabled configuration items to form an internal mapping table, and converts them into compilation parameters for compilation and build. S104, in the Rust project's source code, performs conditional compilation based on compilation parameters, including system-level configurations.

[0006] Secondly, embodiments of the present invention provide a system-level configuration device for the Rust language Cargo package based on Kconfig, comprising: The system-level configuration definition module is used to define the system-level configuration items and corresponding dependencies of all code packages Crate in the Cargo workspace of a Rust project using the Kconfig configuration file, and generate system-level configuration files; The access identifier declaration module is used to configure a preset access identifier in the Cargo.toml file of the code package using a preset configuration build tool, so as to declare that the code package is connected to the Kconfig configuration; The compilation parameter building module is used to receive the command line parameters for starting the build from the user and parse them using the preset configuration build tool. It identifies the system-level configuration file path specified by the configuration path parameter, obtains the system-level configuration file, extracts the enabled configuration items to form an internal mapping table, and converts them into compilation parameters for compilation and build. The conditional compilation module is used to perform conditional compilation, including system-level configurations, in the source code of a Rust project based on compilation parameters.

[0007] Thirdly, embodiments of the present invention provide an electronic device, including: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the above-described system-level configuration method for the Rust language Cargo package based on Kconfig.

[0008] Fourthly, embodiments of the present invention provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to execute the above-described system-level configuration method for the Rust language Cargo package based on Kconfig.

[0009] This invention provides a method and apparatus for system-level configuration of the Rust language Cargo package based on Kconfig. The method uses the Kconfig configuration file to define system-level configuration items and corresponding dependencies for all code packages, forming a system-level configuration file. Then, an access identifier is configured in the Cargo.toml file of the code package to access the Kconfig configuration. Next, the file path is extracted according to the command-line parameters for starting the build input by the user, the corresponding system-level configuration file is read, and the enabled configuration items are traversed to form an internal mapping table, which is then converted into compilation parameters for conditional compilation and build containing system-level configuration. By centrally defining system-level configuration items affecting multiple code packages in the Kconfig file, a .config file is generated as the sole data source for global system-level configuration. All code packages share this same system-level configuration, resolving the issue of fragmented definitions of system-level concepts. Simultaneously, an access identifier is added to the code packages that need to receive system-level configurations, enabling configuration build tools to accurately identify the scope of code packages affected by the system-level configurations. The configuration build tools then automatically complete command-line parsing, configuration file reading, internal mapping table construction, and compilation parameter conversion. Developers only need a single command line to initiate the build process to achieve configuration injection. Enabled configuration items are converted to conditional compilation parameters (--cfg) and feature enable parameters (--features), ensuring that system-level configurations take effect simultaneously at both the Rust compiler level and the Cargo dependency management level, with a completely transparent configuration transfer process. During conditional compilation, the identifier of the system-level configuration corresponds one-to-one with the name of the conditional compilation attribute in the code, eliminating the need for external mapping. Through a two-layer configuration of system-level and package-level configurations, flexible multi-level management of system configurations is achieved for large Rust projects. Attached Figure Description

[0010] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a flowchart illustrating a system-level configuration method for the Cargo package in Rust based on Kconfig, as described in Embodiment 1 of the present invention. Figure 2 This is a flowchart of a system-level configuration method for the Cargo package in Rust based on Kconfig, as described in Embodiment 2 of the present invention. Figure 3 This is a flowchart of a system-level configuration method for the Cargo package in Rust based on Kconfig, as described in Embodiment 2 of the present invention. Figure 4This is a schematic diagram of the structure of a Rust language Cargo package system-level configuration device based on Kconfig, as described in Embodiment 3 of the present invention. Figure 5 This is a structural diagram of the electronic device described in Embodiment 4 of the present invention. Detailed Implementation

[0011] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0012] Example 1 Figure 1 This is a flowchart of a Rust language Cargo package system-level configuration method based on Kconfig, as described in Embodiment 1 of the present invention. It establishes a two-layer configuration logic by defining system-level and package-level configurations, thereby enabling flexible management of configurations for large projects. Specifically, it includes the following steps: S101, in the Cargo workspace of the Rust project, uses the Kconfig configuration file to define the system-level configuration items and corresponding dependencies of all code packages Crate, and generates a system-level configuration file.

[0013] Developers create a `Kconfig` file in the root directory of the Rust project and define a configuration item for each system-level feature using the `Kconfig` syntax. By introducing the Linux kernel's `Kconfig` configuration system at the system-level configuration layer, it serves as a single source of truth for all system-level features (such as SMP, PREEMPT, NET, etc.), allowing for unified definition of the feature's type, default value, dependencies, and mutual exclusion rules through the `Kconfig` file. Simultaneously, the package-level configuration layer retains Cargo's native features mechanism for managing optional features or dependencies within individual crates. Features can still be defined in each crate's `Cargo.toml`, but they no longer bear the responsibility of defining system-level features. The content defined by `Kconfig` includes the configuration item's data type, default value, dependencies with other configuration items, mutual exclusion or automatic selection relationships with other configuration items, and help information. After completing the `Kconfig` file, developers use the `Kconfig` front-end tool to read the defined `Kconfig` file and generate a graphical configuration interface for selecting configuration items. During the selection process, the dependencies, mutual exclusions, and selection relationships between configuration items are automatically verified, and the appropriate configuration item is automatically selected or deselected based on the developer's actions. After all configuration selections are completed, the Kconfig front-end tool generates a .config system-level configuration file in the project root directory. All creates (including third-party dependencies) read the system-level configuration equally from the global configuration file .config and autonomously determine their own behavior based on the configuration (such as which internal features to enable and which dependencies to select). The configuration propagation path is no longer the traditional tree-like propagation (where the upper-level create specifies the features of the lower-level create), but rather all creates access the same global configuration in parallel, thereby ensuring the consistency of system-level features throughout the project.

[0014] S102, using the preset configuration build tool, configures the preset access identifier in the Cargo.toml file of the code package to declare that the code package is connected to the Kconfig configuration.

[0015] For code packages that need to receive system-level configurations and be configured uniformly with the system architecture, a unified access identifier should be configured in the Cargo.toml file of the code package to declare that the code package is connected to the Kconfig configuration system. For example, for code packages that need to change their compilation behavior according to system-level configurations, this can be achieved by adding a custom field explicitly declared in the Cargo.toml file, identified as Kbuild and set to true, to indicate that the code package is connected to the Kconfig configuration system; or by adding an implicitly recognized prefix, identified as CONFIG_, in the Cargo.toml file, which configures the build tools to connect the code package to the Kconfig configuration system when they recognize this prefix.

[0016] S103 receives the command-line parameters for starting the build from the user and parses them using a preset configuration build tool. It identifies the system-level configuration file path specified by the configuration path parameter, obtains the system-level configuration file, extracts the enabled configuration items to form an internal mapping table, and converts them into compilation parameters for compilation and build.

[0017] The pre-defined configuration build tool receives the user's command-line arguments to start the build process, parses them, identifies the system-level configuration file path specified by the `--kconfig` parameter, reads the system-level configuration file at that path, and parses the file content line by line to extract the configuration item names and values. It then creates an internal mapping table for all enabled system-level configuration items marked with a value of 'y'. Simultaneously, it retrieves the list of code packages already connected to the Kconfig configuration system, identified by the access identifier. For each identified code package, it performs dependency verification based on its features section. It identifies instances where upper-level code packages attempt to specify specific sub-features of lower-level dependent code packages, generates error messages to disable these features, and terminates the compilation process for the specified sub-features until verification succeeds. Afterward, each enabled configuration item in the internal mapping table is converted into conditional compilation parameters for the Rust compiler and feature enabling parameters for Cargo. At this point, the native Cargo Build command can be invoked, passing the RUSTFLAGS environment variable and the `--features` command-line argument to start the conditional compilation build process.

[0018] S104, in the Rust project's source code, performs conditional compilation based on compilation parameters, including system-level configurations.

[0019] Developers directly use the passed-in compilation parameters in the Rust source code to perform conditional compilation. Based on the configuration item names defined in Kconfig, the Rust compiler compiles the enabled configuration items one by one, thereby forming the system-level configuration of each package in the Rust project under the system-level architecture.

[0020] It should be noted that the terms "code package" and "Crate" refer to compilation units in the Rust language, i.e., an independent code module or library. The terms "feature" and "characteristic" refer to the feature switching mechanism of the Cargo package manager, used to selectively enable or disable corresponding functions at compile time. The terms "system-level configuration" refer to system architecture-level decision configuration items that affect multiple code packages. The default configuration build tool refers to the wrapper tool used to implement this method, such as Cargo-Kbuild.

[0021] This embodiment uses the Kconfig configuration file to define the system-level configuration items and corresponding dependencies of all code packages, forming a system-level configuration file. Then, the access identifier is configured in the Cargo.toml file of the code package to access the Kconfig configuration. Then, the file path is extracted according to the command line parameters for starting the build input by the user, the corresponding system-level configuration file is read, and the enabled configuration items are traversed to form an internal mapping table, which is converted into compilation parameters for conditional compilation and build containing system-level configuration. By centrally defining system-level configuration items affecting multiple code packages in the Kconfig file, a .config file is generated as the sole data source for global system-level configuration. All code packages share this same system-level configuration, resolving the issue of fragmented definitions of system-level concepts. Simultaneously, an access identifier is added to the code packages that need to receive system-level configurations, enabling configuration build tools to accurately identify the scope of code packages affected by the system-level configurations. The configuration build tools then automatically complete command-line parsing, configuration file reading, internal mapping table construction, and compilation parameter conversion. Developers only need a single command line to initiate the build process to achieve configuration injection. Enabled configuration items are converted to conditional compilation parameters (--cfg) and feature enable parameters (--features), ensuring that system-level configurations take effect simultaneously at both the Rust compiler level and the Cargo dependency management level, with a completely transparent configuration transfer process. During conditional compilation, the identifier of the system-level configuration corresponds one-to-one with the name of the conditional compilation attribute in the code, eliminating the need for external mapping. Through a two-layer configuration of system-level and package-level configurations, flexible multi-level management of system configurations is achieved for large Rust projects.

[0022] Example 2 Figure 2 This is a flowchart of a system-level configuration method for the Rust language Cargo package based on Kconfig, as described in Embodiment 2 of the present invention. This embodiment is an optimization based on the above embodiment. In this embodiment, S101 is specifically optimized as follows: Create a Kconfig configuration file in the root directory of the Rust project. Using Kconfig syntax, define a corresponding system-level configuration item for each system-level feature, including its data type, default value, dependencies, selection relationships, and help information. Generate a .config system-level configuration file in the root directory of the Rust project, while retaining the original package-level configuration features from the Cargo.toml files of each code package.

[0023] Accordingly, the system-level configuration method for the Rust language Cargo package based on Kconfig provided in this embodiment specifically includes: S201. Create a Kconfig configuration file in the root directory of the Rust project. Using Kconfig syntax, define corresponding system-level configuration items for each system-level feature. These items include the data type, default value, dependencies, selection relationships, and help information. Generate a .config system-level configuration file in the root directory of the Rust project, while retaining the original package-level configuration features of the Cargo.toml files of each package.

[0024] The Rust project is based on the Rust language and uses the Cargo workspace to organize its code structure. It includes several packages (Crates), such as the interrupt handling module (kernel_irq), the task management module (kernel_task), and the scheduler module (kernel_schedule). The packages are linked through Cargo's dependency management mechanism. In the development environment, a configuration build tool (such as Cargo-Kbuild) must be pre-installed as a wrapper for Cargo. This wrapper takes over the Cargo build process and inserts Kconfig configuration reading and processing logic. A Kconfig configuration file is created in the Rust project root directory. System-level configuration items include system architecture-level decisions that affect multiple packages, such as symmetric multiprocessor support (SMP), preemptive scheduling (PREEMPT), and network support (NET). These affect the global system's operating mode and therefore must be consistent across multiple modules, rather than being private features of any single package. For example, under the traditional Cargo features mechanism, developers need to repeatedly define the `smp = []` feature in the `Cargo.toml` of each affected package and list the dependencies one by one in the top-level `Cargo.toml`, resulting in the same concept being fragmented and defined in dozens of files. Therefore, by defining system-level configuration items only once in the `Kconfig` file, all packages can read the configuration from the same `.config` file after declaring access via the access identifier. This completely decouples system-level configuration items from their corresponding package-level features, eliminating the need for any system-level configuration item to be repeatedly defined in the `Cargo.toml` of each package. The `[features]` section in each package's `Cargo.toml` is only used to define the package-private package-level configuration and no longer bears the responsibility of defining system-level configurations.

[0025] The content of configuration items includes data types, such as bool (boolean switch), tristate (tristate, which can be used for drivers that can be compiled into modules), int (integer), hex (hexadecimal number), string (string), etc.; default values, specified by the default keyword, such as default y indicating that it is enabled by default; dependencies, using depend on to indicate that the configuration item depends on other configuration items, and the option is only visible or optional when the dependency is satisfied, such as preemptive scheduling (PREEMPT) usually depends on multi-core support (SMP), which can be defined as depend on SMP; selection relationships, using select to indicate that selecting the current item will automatically select other items, often used to express logical binding relationships; help information is provided by help with explanatory text for users to view in the configuration interface. For example, defining bool indicates that the data type of the configuration item is boolean, with a value of enabled (y) or disabled (n); defining default (y) indicates that the default value of the configuration item is enabled; defining depends on SMP indicates that the configuration item depends on the SMP configuration item, and PREEMPT can only be selected when SMP is enabled; defining help provides help information for the configuration item for users to view in the configuration interface.

[0026] Optionally, developers can use Kconfig front-end tools, such as executing the `make menuconfig` command, to read the predefined Kconfig configuration file and generate a corresponding graphical configuration interface for users to make configuration selections. In the graphical interface, users can move the cursor using the arrow keys and select or deselect configuration items using the space bar. Once the selection is complete, the user configuration information is generated.

[0027] During the user's selection of configuration items, the Kconfig front-end tool automatically verifies dependencies. Based on the user's selections in the graphical configuration interface, it automatically associates and selects dependent configuration items according to the selection relationships. For example, when a developer selects a configuration item whose dependency condition is not met, such as selecting PREEMPT when SMP is not enabled, this option is automatically grayed out and unavailable. After the user completes all configuration selections, saves the configuration, and exits, all "depends on" dependencies are checked to ensure the configuration is valid. Finally, a .config system-level configuration file is generated in the Rust project root directory. This file is in plain text format, with each line recording a configuration item in the format of configuration item name=value. A value of 'y' indicates that the configuration item is enabled, while a value of 'n' or the configuration item being commented out indicates that it is not enabled. While generating the .config file, the original [features] section in the Cargo.toml file of each code package is preserved. It is used to define the package-level configuration within each code package, such as the optional serialization function of a certain library. This forms a two-layer configuration system with the system-level configuration. The two are logically independent and do not interfere with each other.

[0028] For large Rust projects containing multiple submodules, developers can split the configuration items of each submodule into multiple subfiles. For example, kernel configuration can be defined in crates / kernel / Kconfig, and driver configuration can be defined in crates / drivers / Kconfig. Then, these subfiles can be imported into the Kconfig configuration file through the source directive in the main Kconfig file to achieve modular organization of configuration items.

[0029] S202 uses a preset configuration build tool to configure a preset access identifier in the Cargo.toml file of the code package to declare that the code package is connected to the Kconfig configuration.

[0030] An optional implementation of this embodiment involves, to inform the build tools which codes need to receive system-level configuration, explicitly declaring an identifier field in the Cargo.toml file of these codes (such as kernel_irq and kernel_task) to allow the build tools to know which codes need to receive system-level configuration (such as SMP or PREEMPT) to change their compilation behavior. When this field is true, the corresponding code package is connected to the Kconfig configuration. For example, a custom field `kbuild` is added to the `[package.metadata]` field of the code package's Cargo.toml file, forming `[package.metadata.kbuild]`, and the `enabled = true` section indicates that the code package is connected to the Kconfig configuration system. When this field is false or not set, it indicates that it is not connected.

[0031] Alternatively, implicit identification features can be defined in the features section of the Cargo.toml file of the code package that needs to receive system-level configuration. For example, features named with the specific prefix CONFIG_ can be defined in the [features] section of the code package's Cargo.toml file, such as CONFIG_SMP = [] and CONFIG_PREEMPT = []. Then, using a pre-defined configuration build tool, the tool checks for the presence of this specific prefix in the [features] section of the code package during scanning. If it is found, the code package is automatically identified as having been integrated into the Kconfig configuration. Both explicit declaration and implicit identification methods can be used simultaneously; when both exist, explicit declaration takes precedence over implicit identification. For code packages without an integration identifier (such as third-party dependency libraries), the configuration build tool considers them not integrated into the Kconfig configuration system and continues to use the traditional Cargo features mechanism, achieving gradual migration and coexistence between old and new code packages. For example, if a package's Cargo.toml contains both `[package.metadata.kbuild] enabled = true` and a CONFIG_ prefix attribute, the explicit declaration takes precedence, and the package is identified as integrated. If a package sets `[package.metadata.kbuild] enabled = false` and defines a CONFIG_ prefix attribute, the explicit declaration takes precedence, and the package is considered not integrated; the build tool ignores the CONFIG_ prefix attribute. If a package does not set an explicit declaration field but defines a CONFIG_ prefix attribute, it is automatically integrated through implicit identification.

[0032] S203 receives the command-line parameters for starting the build from the user and parses them using a preset configuration build tool. It identifies the system-level configuration file path specified by the configuration path parameter, obtains the system-level configuration file, extracts the enabled configuration items to form an internal mapping table, and converts them into compilation parameters for compilation and build.

[0033] S204, in the Rust project's source code, performs conditional compilation based on compilation parameters, including system-level configurations.

[0034] This embodiment defines corresponding system-level configuration items for each system-level feature in the Kconfig configuration file using Kconfig syntax, generates a .config system-level configuration file in the root directory of the Rust project, and retains the original package-level configuration features of the Cargo.toml files of each code package; generates a graphical configuration interface for users to select configurations and automatically performs dependency verification, checking all dependencies after all operations are completed; explicitly declares the identification fields and implicitly identifies the code package to be connected to the Kconfig configuration for the configuration build tool to recognize; for large Rust projects containing multiple submodules, each configuration item is split into multiple subfiles and imported into the Kconfig configuration file through the source directive. By defining data types, default values, dependencies, selection relationships, and help information for each system-level feature in the Kconfig configuration file, the configuration item definitions are complete and self-descriptive. Dependency checks are performed during the configuration phase using the Kconfig front-end tool, ensuring that configuration errors are detected and corrected before compilation begins, avoiding compilation failures caused by configuration errors in the traditional Cargo features mode. A dual-mode access mechanism, employing both explicit declaration of identifier fields and implicit feature identification methods with clearly defined priority rules, provides a hierarchical configuration definition foundation for the progressive architectural evolution of large projects. This makes system and configuration definitions standardized and easy to operate, while pre-configuration verification and modular project organization make code package access more flexible.

[0035] Example 3 Figure 3 This is a flowchart of a system-level configuration method for the Rust language Cargo package based on Kconfig, as described in Embodiment 3 of the present invention. This embodiment is an optimization based on the above embodiment. In this embodiment, S103 is specifically optimized as follows: It receives command-line parameters input by the user, parses them using a preset configuration building tool to obtain the path of the system-level configuration file, reads and parses the corresponding system-level configuration file, extracts all enabled configuration items, and forms an internal mapping table. The pre-defined configuration build tool iterates through all the code packages in the Cargo workspace, reads the Cargo.toml file of each code package, and identifies the code packages that have been connected to the Kconfig configuration based on the pre-defined access identifier. For each identified code package, the default configuration build tool is used to perform dependency verification on its feature segments, check and prohibit specified sub-features, and declare the prohibited sub-features into the Kconfig configuration through a default access identifier; After dependency verification is completed, the preset configuration build tool is used to convert the parameters of each enabled configuration item to obtain conditional compilation parameters and feature enabling parameters, and then the compilation and build are performed.

[0036] Accordingly, the system-level configuration method for the Rust language Cargo package based on Kconfig provided in this embodiment specifically includes: S301, in the Cargo workspace of the Rust project, uses the Kconfig configuration file to define the system-level configuration items and corresponding dependencies of all code packages Crate, and generates a system-level configuration file.

[0037] S302 uses a preset configuration build tool to configure a preset access identifier in the Cargo.toml file of the code package to declare that the code package is connected to the Kconfig configuration.

[0038] S303 receives command-line parameters input by the user, parses them using a preset configuration building tool, identifies the system-level configuration file path specified by the --kconfig parameter, reads and parses the corresponding system-level configuration file, extracts all enabled configuration items, and forms an internal mapping table.

[0039] Upon receiving command-line arguments from the user to initiate system configuration build, the pre-defined configuration build tool parses the input command-line arguments to obtain the path to the specified system-level configuration file. Then, it reads the corresponding system-level configuration file based on this path, and continues to parse it using the configuration build tool to identify all enabled configuration items and form an internal mapping table. For example, the user-input command-line argument might be `cargo-kbuild`. <cargo-command>[cargo-args] --kconfig <config-file>, where cargo-kbuild is the name of the command that configures the build tools; <cargo-command>This section lists Cargo's native commands, including `build`, `run`, `test`, and `bench`. `[cargo-args]` contains the arguments passed to these Cargo commands. `--kconfig.config` specifies the path to the system-level configuration file. The path to the `.config` file can be obtained by parsing the command-line arguments and extracting the value of the `--kconfig` parameter. When the user omits the `--kconfig` parameter, the build tools default to reading the `.config` file in the project's root directory.

[0040] After obtaining the system-level configuration file, the file content is parsed line by line. For each line, comment lines starting with the '#' character and blank lines are skipped. For lines prefixed with 'CONFIG_' and with a value of '=Y', the configuration item names on the left side of the equals sign and the values ​​on the right side are extracted. All enabled configuration items with a value of 'y' are extracted to form an internal mapping table. For example, after traversing the .config file, three configuration items are extracted: 'CONFIG_SMP=Y', 'CONFIG_PREEMPT=Y', and 'CONFIG_NET=Y'. The resulting internal mapping table is {"CONFIG_SMP": "y","CONFIG_PREEMPT": "y","CONFIG_NET": "y"}.

[0041] S304 uses a preset configuration build tool to traverse all code packages in the Cargo workspace, reads the Cargo.toml file of each code package, and identifies the code packages that have been connected to the Kconfig configuration based on the preset access identifier.

[0042] The configuration build tool iterates through all packages in the Cargo workspace, reading the Cargo.toml file for each package. Information about the Cargo workspace can be obtained by reading the [workspace] section of the Cargo.toml file located in the project root directory. For each package, the configuration build tool identifies the list of packages integrated into the Kconfig configuration system based on configured integration identifiers, including explicitly declared [package.metadata.kbuild] fields or implicitly recognized CONFIG_ prefix features. Due to the priority of explicit declarations, it first checks if a [package.metadata.kbuild] section exists with the enabled field set to true. If it does, the package is considered integrated into the Kconfig configuration system. If no explicit declaration exists or the enabled field is not true, it checks if the package's [features] section contains feature definitions starting with CONFIG_. If so, it implicitly identifies the package as integrated into the Kconfig configuration system. If neither method matches, the package is considered not integrated into the Kconfig configuration system, and the configuration build tool will not inject configuration into it in subsequent processing.

[0043] S305 performs dependency verification on the feature segments of each identified code package using a preset configuration build tool, checks and prohibits specified sub-features, and declares the prohibited sub-features into the Kconfig configuration through a preset access identifier.

[0044] For each package identified as integrated into the Kconfig configuration system, the configuration build tool performs dependency verification based on the [features] section of its Cargo.toml file. First, the tool iterates through all features starting with CONFIG_ in the package's [features] section, reading the dependency list for each feature. For each dependency, it checks its string representation for a forward slash character ( / ). If any dependency contains a forward slash character (e.g., tokio / rt-multi-thread), it is considered an invalid format. This format indicates that the upper-level package (the current package) is attempting to specify a specific sub-feature (rt-multi-thread) of the lower-level dependent package (the tokio package). This method of specification conflicts with the Kconfig configuration system's principle that all packages should read configurations equally from the global configuration file. Instead, the dependent package itself must decide which sub-features to enable based on the global configuration, not the upper-level package. Upon detecting this invalid format, the configuration build tool generates an error message and terminates the compilation and build process. For example, the error message includes the name of the conflicting package, the name of the conflicting feature, the content of the illegal dependency, and corresponding modification suggestions, such as changing tokio / rt-multi-thread to tokio, and ensuring that tokio itself declares its connection to the Kconfig configuration system through the access identifier, allowing tokio itself to decide which sub-features to enable based on the global configuration. If all dependencies do not contain forward slash characters (i.e., only declare dependencies on other packages, such as tokio, without specifying its sub-features), then dependency verification passes, and the configuration build tool continues execution.

[0045] S306 After completing dependency verification, the preset configuration build tool is used to convert the parameters of each enabled configuration item to obtain conditional compilation parameters and feature enabling parameters, and then the compilation and build are performed.

[0046] After dependency verification passes, the configuration build tool converts each enabled configuration item in its internal mapping table into two types of compilation parameters. The first type consists of Rust compiler conditional compilation parameters, formatted as `--cfg CONFIG_SMP`. All parameters of this type are concatenated with spaces and passed to the Rust compiler via the `RUSTFLAGS` environment variable. The second type consists of Cargo feature enabling parameters, formatted as `--features` followed by a comma-separated list of configuration item names, passed to Cargo via command-line arguments. For example, for the enabled `CONFIG_SMP` and `CONFIG_PREEMPT`, the generated `RUSTFLAGS` is `--cfgCONFIG_SMP --cfg CONFIG_PREEMPT`; the generated `--features` parameters are `CONFIG_SMP` and `CONFIG_PREEMPT`. The configuration build tool then calls the native Cargo Build command, passing in the `RUSTFLAGS` environment variable and the `--features` command-line argument, to initiate the actual compilation and build process.

[0047] An optional implementation of this embodiment is to convert each enabled configuration item into a conditional compilation parameter through the RUSTFLAGS environment variable, and to convert each enabled configuration item into a feature enabling parameter through the features command-line parameter, and then call the native Cargo Build command to compile and build.

[0048] Before invoking the native Cargo command, the configuration build tool sets an environment variable named RUSTFLAGS in the current process environment, with a value that is the concatenation of all `--cfg CONFIG_` parameters. When Cargo invokes the Rust compiler, it automatically reads the contents of the RUSTFLAGS environment variable and passes it as an additional parameter to rustc. Upon receiving the `--cfgCONFIG_` parameter, the Rust compiler treats it as a conditional compilation flag during the compilation process, making the `#[cfg(CONFIG_XXX)]` attribute in the source code effective. When invoking the native Cargo command, the configuration build tool appends the `--features` parameter to the command line, followed by a comma-separated list of configuration item names. When resolving dependencies, Cargo enables the features in the corresponding `[features]` section of each package's `Cargo.toml` based on the feature names specified in the `--features` parameter, thereby triggering the corresponding optional dependencies—that is, dependencies marked as `optional = true` in `[dependencies]`—and including them in the compilation. The two methods described above work together and take effect simultaneously. The RUSTFLAGS environment variable is used to control the conditional compilation behavior of the Rust compiler, and the --features attribute is used to control Cargo's dependency resolution and feature enabling behavior. Together, they ensure that the system-level configuration takes full effect at both the code compilation and dependency management levels.

[0049] S307, in the Rust project's source code, performs conditional compilation based on compilation parameters, including system-level configurations.

[0050] For example, in the Rust source code, developers can directly use the `#[cfg(CONFIG_XXX)]` attribute for conditional compilation, where `CONFIG_XXX` refers to the configuration item names defined in `kconfig`. For instance, `#[cfg(CONFIG_SMP)]` means compiling the code block only when SMP is enabled; `#[cfg(not(CONFIG_SMP))]` means compiling only when SMP is disabled; `#[cfg(all(CONFIG_SMP, CONFIG_PREEMPT))]` means compiling only when both SMP and PREEMPT are enabled; and `#[cfg(any(CONFIG_X86, CONFIG_ARM64))]` means compiling on either the x86 or ARM64 platform. Compared to the conditional compilation of traditional Cargo features, this provides more explicit semantic information and directly reflects system-level configuration.

[0051] Optionally, for configuration items of integer or string type, environment variables can be read and parsed using the environment variable method, or a pre-defined configuration building tool can be used to generate code files and extract the constant definitions of each configuration item.

[0052] For configuration items with integer (int) and string (string) data types, their values ​​cannot be passed via the `--cfg` boolean parameter. In this case, when the configuration build tool calls the native `Cargo` command, in addition to setting the `RUSTFLAGS` environment variable, it also needs to pass each integer and string configuration item as an environment variable. For example, for the configuration item `CONFIG_LOG_LEVEL=3`, the configuration build tool sets the environment variable to `CONFIG_LOG_LEVEL=3`. For example, during compilation, `option_env!("CONFIG_LOG_LEVEL")` is used to read the environment variable and parse it into the required type, such as defining a constant in the code: `const LOG_LEVEL:usize=match option_env!("CONFIG_LOG_LEVEL"){Some(val) => val.parse().unwrap_or(3),None =>3}`. Alternatively, the build tool can automatically generate a Rust source code file containing the constant definitions of all configuration items during the compilation process. This file is located in the Cargo output directory and contains the constant definitions for each configuration item. Once included, developers can directly use these constants in their code without needing runtime resolution via environment variables. For example, the build tool can automatically generate a `config.rs` file containing the constant definitions for all configuration items, such as `pub const CONFIG_LOG_LEVEL: usize = 3`. Developers can simply include this file in their code using the `include!` macro, such as: `include!(concat!(env!("OUT_DIR"), " / config.rs"))`.

[0053] Furthermore, for third-party dependencies that require specific system configurations, developers can declare them as optional in the `Cargo.toml` file of the crate package, and then establish a mapping from `CONFIG_feature` to that dependency in the `[features]` section. When `CONFIG_NET` is enabled in the global configuration, the `--features` parameter generated by the configuration build tool will include `CONFIG_NET`, thereby triggering Cargo to enable the `tokio` dependency. This maintains compatibility with the Cargo ecosystem while delegating dependency selection to system-level configuration.

[0054] This embodiment obtains the system-level configuration file path by parsing the command-line parameters input by the user using a configuration build tool, reads the corresponding system-level configuration file, and extracts all enabled configuration items to form an internal mapping table. It then traverses all code packages in the Cargo workspace, reads the Cargo.toml file of each package, and identifies the code packages that have been integrated into the Kconfig configuration based on the access identifier. Next, it uses a preset configuration build tool to perform dependency verification on the feature segments, checks and disables specified sub-features, and declares the disabled sub-features as integrated into the Kconfig configuration using a preset access identifier. After dependency verification, it uses the preset configuration build tool to perform parameter conversion on each enabled configuration item, obtaining conditional compilation parameters and feature enabling parameters, and then performs compilation and build. It converts each enabled configuration item into conditional compilation parameters using the RUSTFLAGS environment variable and into feature enabling parameters using the features command-line parameters, and then calls the native Cargo Build command to perform compilation and build. By configuring the build tool to parse command-line arguments and read specified system-level configuration files, it enables the maintenance of multiple configuration files within a single codebase. This allows for quick and flexible configuration switching during the build process via command-line arguments, without requiring modification of the source code or the Cargo.toml file. By traversing and identifying access identifiers, it accurately locates the set of code packages that need to receive system-level configurations. Dependency verification of the feature segments of already accessed code packages and disabling the specification of sub-features creates a parallel access architecture. All code packages can only declare dependencies on other code packages and cannot determine their internal configurations, thus overcoming the problem of dispersed configuration control caused by the traditional Cargo features tree-like passing mode and ensuring global consistency of system-level configurations across the project. By simultaneously converting enabled configuration items into the `--cfg` parameter and `--features` command-line argument in `RUSTFLAGS`, it ensures that system-level configurations take effect synchronously at the Rust compiler conditional compilation level and the Cargo dependency management level, fully utilizing the native parameter passing interfaces of Cargo and Rustc without modifying the Cargo or Rustc source code.

[0055] Example 4 Figure 4 This is a schematic diagram of a system-level configuration device for the Rust language Cargo package based on Kconfig, as described in Embodiment 4 of the present invention. In this embodiment, the system-level configuration device for the Rust language Cargo package based on Kconfig includes: The system-level configuration definition module 810 is used to define the system-level configuration items and corresponding dependencies of all code packages Crate in the Cargo workspace of a Rust project using the Kconfig configuration file, and generate a system-level configuration file. The access identifier declaration module 820 is used to configure a preset access identifier in the Cargo.toml file of the code package using a preset configuration build tool, so as to declare that the code package is connected to the Kconfig configuration; The compilation parameter building module 830 is used to receive the command line parameters for starting the build from the user and parse them using the preset configuration build tool. It identifies the system-level configuration file path to obtain the system-level configuration file, extracts the enabled configuration items to form an internal mapping table, and converts them into compilation parameters for compilation and build. The conditional compilation module 840 is used to perform conditional compilation, including system-level configurations, in the source code of a Rust project based on compilation parameters.

[0056] This embodiment defines system-level configuration items for all code packages through a system-level configuration definition module, configures preset access identifiers through an access identifier declaration module, extracts system-level configuration items and converts them into compilation parameters through a compilation parameter construction module, and performs conditional compilation of the system-level configurations based on the converted compilation parameters through a conditional compilation module. By centrally defining system-level configuration items affecting multiple code packages in the Kconfig file, a .config file is generated as the sole data source for global system-level configuration. All code packages share this same system-level configuration, resolving the issue of fragmented definitions of system-level concepts. Simultaneously, an access identifier is added to the code packages that need to receive system-level configurations, enabling configuration build tools to accurately identify the scope of code packages affected by the system-level configurations. The configuration build tools then automatically complete command-line parsing, configuration file reading, internal mapping table construction, and compilation parameter conversion. Developers only need a single command line to initiate the build process to achieve configuration injection. Enabled configuration items are converted to conditional compilation parameters (--cfg) and feature enable parameters (--features), ensuring that system-level configurations take effect simultaneously at both the Rust compiler level and the Cargo dependency management level, with a completely transparent configuration transfer process. During conditional compilation, the identifier of the system-level configuration corresponds one-to-one with the name of the conditional compilation attribute in the code, eliminating the need for external mapping. Through a two-layer configuration of system-level and package-level configurations, flexible multi-level management of system configurations is achieved for large Rust projects.

[0057] The Rust language Cargo package system-level configuration device based on Kconfig provided in this embodiment of the invention can execute the Rust language Cargo package system-level configuration method based on Kconfig provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0058] Example 5 Figure 5 This is a structural diagram of an electronic device according to Embodiment 5 of the present invention. Figure 5 A block diagram is shown of an exemplary electronic device 12 suitable for implementing embodiments of the present invention. Figure 5 The electronic device 12 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0059] like Figure 5 As shown, the electronic device 12 is represented in the form of a general-purpose computing device. The components of the electronic device 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processing unit 16).

[0060] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0061] Electronic device 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by electronic device 12, including volatile and non-volatile media, removable and non-removable media.

[0062] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. Electronic device 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (… Figure 5 Not shown; usually referred to as a "hard drive"). Although Figure 5 As not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. System memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0063] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28. Such program modules 42 include, but are 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. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.

[0064] Electronic device 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), and with one or more devices that enable a user to interact with the electronic device 12 / server / computer, and / or with any device that enables the electronic device 12 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed through input / output (I / O) interface 22. Furthermore, electronic device 12 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 20. Figure 5 As shown, network adapter 20 communicates with other modules of electronic device 12 via bus 18. It should be understood that, although... Figure 5 As not shown, other hardware and / or software modules may be used in conjunction with electronic device 12, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0065] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing the system-level configuration method of the Rust language Cargo package based on Kconfig provided in this embodiment of the invention.

[0066] Example 6 Embodiment 6 of the present invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to execute the system-level configuration method for the Rust language Cargo package based on Kconfig provided in the above embodiments.

[0067] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can 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 computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer 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 device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0068] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-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. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0069] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including, but not limited to, wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0070] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0071] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A system-level configuration method for the Cargo package in Rust based on Kconfig, characterized in that, include: S101, in the Cargo workspace of the Rust project, uses the Kconfig configuration file to define the system-level configuration items and corresponding dependencies of all code packages Crate, and generates a system-level configuration file; S102, using the preset configuration build tool, configure the preset access identifier in the Cargo.toml file of the code package to declare that the code package is connected to the Kconfig configuration; S103 receives the command-line parameters for starting the build input from the user and parses them using a preset configuration build tool. It identifies the system-level configuration file path specified by the configuration path parameter to obtain the system-level configuration file, extracts the enabled configuration items to form an internal mapping table, and converts them into compilation parameters for compilation and build. S104, in the Rust project's source code, performs conditional compilation based on compilation parameters, including system-level configurations.

2. The method according to claim 1, characterized in that, S101 further includes: Create a Kconfig configuration file in the root directory of the Rust project, and use Kconfig syntax to define corresponding system-level configuration items for each system-level feature in the Kconfig configuration file, including the data type, default value, dependency, selection relationship and help information of the configuration item. Generate a .config system-level configuration file in the root directory of the Rust project, while retaining the original package-level configuration features of the Cargo.toml file of each code package.

3. The method according to claim 2, characterized in that, S101 further includes: The Kconfig front-end tool is used to generate a graphical configuration interface based on the defined Kconfig configuration file, allowing users to make configuration selections and forming user configuration information; The Kconfig front-end tool performs dependency checks on configuration items, grays out configuration items with unmet dependencies, and automatically associates and selects dependent configuration items based on the user's selection operations in the graphical configuration interface and the selection relationship of configuration items. After the user has completed all configuration selection operations, it checks all dependencies. For large Rust projects containing multiple submodules, split each configuration item into multiple subfiles and import the Kconfig configuration file using the source directive.

4. The method according to claim 1, characterized in that, The preset access identifier includes: Configure an explicit declaration field in the Cargo.toml file of the code package that needs to receive system-level configuration. When the value of this field is true, the corresponding code package will be connected to the Kconfig configuration. Alternatively, implicit identification features can be defined in the feature section of the Cargo.toml file that needs to receive system-level configuration, and the corresponding code package can be identified and integrated into the Kconfig configuration using a preset configuration building tool.

5. The method according to claim 1, characterized in that, S103 includes: It receives command-line parameters input by the user, parses them using a preset configuration building tool, identifies the system-level configuration file path specified by the --kconfig parameter, reads and parses the corresponding system-level configuration file, extracts all enabled configuration items, and forms an internal mapping table. The pre-defined configuration build tool iterates through all the code packages in the Cargo workspace, reads the Cargo.toml file of each code package, and identifies the code packages that have been connected to the Kconfig configuration based on the pre-defined access identifier. For each identified code package, the default configuration build tool is used to perform dependency verification on its feature segments, check and prohibit specified sub-features, and declare the prohibited sub-features into the Kconfig configuration through a default access identifier; After dependency verification is completed, the preset configuration build tool is used to convert the parameters of each enabled configuration item to obtain conditional compilation parameters and feature enabling parameters, and then the compilation and build are performed.

6. The method according to claim 5, characterized in that, S103 further includes: Each enabled configuration item is converted into a conditional compilation parameter through the RUSTFLAGS environment variable, and each enabled configuration item is converted into a feature enabling parameter through the features command-line parameter. Then, the native Cargo Build command is called to compile and build.

7. The method according to claim 1, characterized in that, S104 further includes: For configuration items of integer and string types, the environment variables are read and parsed using the environment variable method, or the code file is generated using the preset configuration building tool and the constant definitions of each configuration item are extracted.

8. A system-level configuration apparatus for the Rust language Cargo package based on Kconfig, used to implement the system-level configuration method for the Rust language Cargo package based on Kconfig as described in any one of claims 1-7, characterized in that, include: The system-level configuration definition module is used to define the system-level configuration items and corresponding dependencies of all code packages Crate in the Cargo workspace of a Rust project using the Kconfig configuration file, and generate system-level configuration files; The access identifier declaration module is used to configure a preset access identifier in the Cargo.toml file of the code package using a preset configuration build tool, so as to declare that the code package is connected to the Kconfig configuration; The compilation parameter building module is used to receive the command line parameters for starting the build from the user and parse them using the preset configuration build tool. It identifies the system-level configuration file path specified by the configuration path parameter, obtains the system-level configuration file, extracts the enabled configuration items to form an internal mapping table, and converts them into compilation parameters for compilation and build. The conditional compilation module is used to perform conditional compilation, including system-level configurations, in the source code of a Rust project based on compilation parameters.

9. An electronic device, characterized in that, The electronic device includes: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the system-level configuration method for the Rust language Cargo package based on Kconfig as described in any one of claims 1-7.

10. A storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the system-level configuration method for the Rust language Cargo package based on Kconfig as described in any one of claims 1-7.

Images