A configuration method and device of an apparatus, an electronic device, and a storage medium

Abstract

This application relates to the field of computer technology and provides a device configuration method, apparatus, electronic device, and storage medium. The method, during the system startup phase of the target device, reads the hardware identification information of the target device; based on the hardware identification information, calls the corresponding feature configuration file of the target device from a pre-set device feature configuration library; initializes the target device according to the feature configuration file; and generates a unified hardware operation interface based on the feature configuration file, allowing upper-layer applications to control the hardware components of the target device through the hardware operation interface. This application, by automatically identifying the hardware identifier and loading the matching feature configuration file during the system startup phase, dynamically constructs a unified hardware operation interface, achieving complete decoupling between upper-layer business software and the underlying hardware platform. This significantly improves code reusability and system portability, avoiding the problems of high code duplication and low code reusability in software development.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a device configuration method and device, electronic device and storage medium. BACKGROUND

[0002] In the development of network devices (such as switches, gateways, industrial routers), manufacturers usually need to develop bottom-layer drivers and control logic for different models of devices (for example, device A, device B, device C) respectively. Due to the differences in hardware layout, chip selection, GPIO allocation, sensor interface, etc. of each device, the software development is highly repetitive, the maintenance cost is high, and the adaptation period is long. SUMMARY

[0003] Therefore, the embodiments of the present application provide a device configuration method and device, electronic device and storage medium to solve the problem of high code redundancy and low code reuse in the prior art.

[0004] The first aspect of the embodiments of the present application provides a device configuration method, which comprises: reading hardware identification information of a target device in a system startup stage of the target device; calling a feature configuration file corresponding to the target device from a preset device feature configuration library according to the hardware identification information; initializing the target device according to the feature configuration file, and generating a unified hardware operation interface according to the feature configuration file, so as to control hardware components of the target device by the hardware operation interface through an upper-layer application. The second aspect of the embodiments of the present application provides a device configuration device, which comprises: a reading module configured to read hardware identification information of a target device in a system startup stage of the target device; a feature module configured to call a feature configuration file corresponding to the target device from a preset device feature configuration library according to the hardware identification information; and a configuration module configured to initialize the target device according to the feature configuration file, and generate a unified hardware operation interface according to the feature configuration file, so as to control hardware components of the target device by the hardware operation interface through an upper-layer application.

[0005] The third aspect of the embodiments of the present application provides an electronic device, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the steps of the above method when executing the computer program.

[0006] The fourth aspect of the embodiments of the present application provides a computer-readable storage medium, which stores a computer program, and the computer program implements the steps of the above method when executed by a processor.

[0007] Compared with the prior art, the embodiment of the present application has the beneficial effects that: the method of the embodiment of the present application reads the hardware identification information of the target device in the system startup stage of the target device; according to the hardware identification information, the corresponding feature configuration file of the target device is called from the preset device feature configuration library; the target device is initialized according to the feature configuration file, and a unified hardware operation interface is generated according to the feature configuration file, so as to control the hardware components of the target device by the upper layer application through the hardware operation interface. The present application automatically identifies the hardware identification and loads the matching feature configuration file in the system startup stage, dynamically constructs a unified hardware operation interface, realizes the complete decoupling of the upper layer business software and the bottom layer hardware platform, solves the code fragmentation problem in the traditional "one machine one code" mode, realizes the rapid adaptation and "zero code" expansion of multiple models of devices without modifying the core code, significantly improves the code reuse rate and system portability, avoids the problems of high code repetition and low code reuse rate, and at the same time, shields the bottom layer physical difference through the unified interface, effectively avoids the risk of misoperation in the startup stage, and guarantees the reliability of device operation. BRIEF DESCRIPTION OF DRAWINGS

[0008] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or the prior art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0009] Figure 1 is a flow diagram of a device configuration method provided by the embodiment of the present application; Figure 2 is a schematic diagram of another device configuration method provided by the embodiment of the present application; Figure 3 is a schematic diagram of a device configuration device provided by the embodiment of the present application; Figure 4 is a structural schematic diagram of an electronic device provided by the embodiment of the present application. DETAILED DESCRIPTION

[0010] In the following description, specific details such as specific system structures, techniques, etc. are presented in order to thoroughly understand the embodiments of the present application. However, it should be clear to those skilled in the art that the present application can also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known system, device configuration, circuit and method are omitted to avoid unnecessary details that hinder the description of the present application.

[0011] A configuration method of a device and a configuration apparatus of the device will be explained in detail below with reference to the accompanying drawings.

[0012] Figure 1 A configuration method of a device provided by the embodiments of the present application, as shown in the figure, comprises the following steps. Figure 1 S101, reading the hardware identification information of the target device in the system startup stage of the target device; S102, calling the corresponding feature configuration file of the target device from the preset device feature configuration library according to the hardware identification information; S103, initializing the target device according to the feature configuration file, and generating a unified hardware operation interface according to the feature configuration file, so as to control the hardware components of the target device through the hardware operation interface by the upper application.

[0013] It can be understood that in actual application scenarios, manufacturers usually develop multiple devices (for example, device model A, device model B, and device model C) of different specifications based on the same set of software code (for example, Firmware / OS Image). Although these devices run the same operating system kernel, there are significant differences in the hardware level, for example, the physical slot of the network interface card (NIC) is different, the trigger logic of the bypass control circuit (BYPASS) is different (some are GPIO high level trigger, and some are register set trigger), or the GPIO pin number connected by the status indicator light (LED) is different.

[0014] Among them, the target device refers to the physical network device currently carrying and executing the configuration method of the device. It can be any one of the above device model A, device model B, or device model C entity. Since the same general firmware is burned into these devices when they are shipped, they are unknown black boxes to the software before the physical appearance or internal circuit is identified by the software.

[0015] Since the embodiments of the present application adopt the design architecture of "general firmware", when the target device is powered on and reset (Power-On Reset) or the operating system kernel (Kernel) is just starting to load, the general software program running in the memory is still in the "blind state". It does not know whether it is currently running on "device model A" or "device model B". If the hard-coded parameters (such as the default operation GPIO 10) are directly used to control the hardware at this time, serious compatibility accidents may occur - for example, the GPIO 10 of device A is an LED light, while the GPIO 10 of device B is actually connected to the system reset pin, and the wrong operation will directly cause system crash or hardware damage.

[0016] ​Therefore, the application first performs the step of reading the hardware identification information in the system startup phase of the target device, to eliminate the "blind state", accurately determine the specific device model of the target device (i.e. explicitly whether the current device identity is "device model A" or "device model B"), and thus provide a unique basis for subsequent loading of the correct feature configuration file.

[0017] It can be understood that the hardware identification information of the target device can specifically include at least one of the following information: device model number (Device Model Number): usually stored in a specific offset address of the non-volatile memory (such as EEPROM or Flash) of the motherboard. The system can drive reading of this storage area through the I2C bus or SPI bus, and obtain the string (such as "Model-Gateway-X1") pre-written by the manufacturer. PCIE device identification (PCIE Device ID): suitable for scenarios of distinguishing device models through different expansion cards. The system can read the Vendor ID and Device ID of the device on a specific slot through PCI / PCIe bus enumeration. For example, device A identifies an Intel network card on slot 1, while device B identifies a Broadcom network card, thereby distinguishing the device types. System management BIOS information (SMBIOS / DMI): suitable for x86 architecture devices. The system can directly obtain the product model information burned in the BIOS by reading / sys / class / dmi / id / product_name or calling the dmidecode tool. Specific general-purpose input / output (GPIO) level combination: this is a commonly used "hardware Strapping" method in embedded systems. A set of GPIO pins (for example, 3 pins) are reserved during motherboard design, and different high / low level combinations (001, 010, 100) are configured through pull-up resistors or pull-down resistors. The system reads the state register of this set of GPIOs when starting, and takes the binary value as the hardware ID. This method has the lowest cost and is extremely reliable.

[0018] It can be understood that different hardware identification information has different reading methods; for example, for the reading of non-volatile memory, when the hardware identification information is the device model number, the processor sends a read instruction to the EEPROM or Flash chip through the low-speed bus (such as the I2C or SPI bus) on the motherboard. Specifically, the system driver program accesses the pre-agreed memory offset address (Offset Address), such as reading the byte sequence between addresses 0x00 and 0x10. After ASCII conversion of the raw binary data, a string such as "Model-Gateway-X1" can be obtained.

[0019] For accessing system hardware interfaces, when the hardware identification information is a PCIe device identifier or SMBIOS information, the system does not need to directly operate the underlying circuitry. Instead, it obtains the information by accessing the hardware interfaces exposed by the operating system kernel. For PCIe device identifiers, the system performs a bus enumeration operation, traversing the PCI configuration space. By reading the Vendor ID and Device ID registers under a specific bus number, device number, and function number (BDF), and comparing them with a pre-set ID list, it determines whether the current device has a specific model of network card or accelerator card mounted. For SMBIOS information, the system directly calls the kernel interface to read the Desktop Management Interface (DMI) table. For example, in a Linux system, by reading the contents of the file system path / sys / class / dmi / id / product_name, it directly obtains the device model string burned into the BIOS at the factory.

[0020] For hardware pin status detection, when the hardware identification information corresponds to a specific GPIO level combination, the processor directly reads the input data register of the general-purpose input / output controller (GPIO controller). Specifically, the system masks the bits of irrelevant pins and only extracts the level status (0 or 1) of the GPIO pins used for hardware strapping. For example, if GPIO_1, GPIO_2, and GPIO_3 read low, high, and low respectively, the resulting hardware ID is binary 010. This method does not rely on the file system or external bus and is the fastest way to complete identification in the very early stages of system startup (Bootloader stage).

[0021] Since different models of devices may only reserve one of the above identification methods (for example, device model A only has GPIO identification, while device model B only has EEPROM identification), or for the sake of boot speed considerations, the step S101 of reading hardware identification information does not require all of the above operations to be performed at the same time. That is, the step of reading the non-volatile memory of the target device, accessing the system hardware interface, or detecting the hardware pin status to obtain hardware identification information may include performing any one or more combinations of these operations.

[0022] In some examples, this application pre-configures an "identifier read priority policy." The identifier read priority policy explicitly defines the predetermined sequence for the system to access different hardware identifier sources during startup and the termination condition for stopping the scan. Specifically, to achieve FastBoot, the system sets the fastest reading method (such as GPIO read) as the highest priority. If it is determined that a valid device model has been successfully matched by reading the GPIO level combination (e.g., reading binary '010', and this value corresponds to 'device model A' in the database), the system can read only this identifier information and directly skip the subsequent time-consuming PCIe scan or EEPROM read operations.

[0023] For example, during system startup, the GPIO status is checked first. Once the status is successfully identified, the configuration for device model A is loaded immediately. Only if the GPIO read fails or the read value is invalid (such as '000') will the system fall back to the step of reading the EEPROM or scanning the PCIe device ID. This strategy ensures compatibility while minimizing system initialization time.

[0024] In some examples, in order to obtain hardware identification information more accurately and completely, step S101 may also simultaneously perform reading the non-volatile memory of the target device, accessing the system hardware interface, and detecting the hardware pin status to obtain hardware identification information.

[0025] Specifically, this approach employs a "multiple redundancy check strategy." In industrial control or high-reliability network scenarios, to prevent incorrect device model identification due to a single hardware failure (such as a GPIO pin reading error caused by a poor solder joint), the system collects hardware identifiers obtained through multiple methods and performs a consistency comparison.

[0026] For example, the system simultaneously reads the GPIO status (obtaining ID_A) and the serial number in the EEPROM (obtaining ID_B). Only when ID_A and ID_B both point to the same device model (e.g., "Device Model A") will the system determine that the identification is successful and load the configuration; if the two are inconsistent (e.g., the GPIO shows device A, but the EEPROM shows device B), the system will trigger an alarm or enter SafeMode, and will not load potentially incorrect driver configurations, thereby greatly improving the system's robustness and security in harsh hardware environments.

[0027] After obtaining the hardware identification information of the target device, this application will call the corresponding feature configuration file of the target device from the pre-built device feature configuration library based on the hardware identification information. It is understood that the pre-built device feature configuration library can be stored in a database, or it can be a set of structured files stored in a specific path of the target device's file system (e.g., / etc / board_config / ), or a read-only data partition packaged in the firmware image.

[0028] When calling the feature configuration file, this embodiment of the application adopts an "ID-file mapping mechanism". The system internally maintains a device model mapping table (DeviceMapTable), which records the one-to-one correspondence between "hardware identification information" and "feature configuration file path".

[0029] For example, suppose the hardware identification information read in step S101 is the string "Board_ID_1001". The system queries the mapping table and finds that the configuration file corresponding to this ID is named config_model_A.json. Therefore, based on this filename, the system loads the corresponding file content from the device feature configuration library into memory.

[0030] It is understandable that the feature configuration file is written in a structured data format (such as JSON, XML or YAML). Its content is not a simple key-value pair, but defines the hardware physical parameters and business control logic associated with the device model corresponding to the target device through a hierarchical structure.

[0031] For example, a typical feature configuration file (such as config_model_A.json) might contain the following definitions: Physical layer definition: "bypass_relay":{"type":"gpio","pin":50,"active_level":1} (indicating that the BYPASS relay is controlled by GPIO50 and is activated when the level is high); Logical layer definition: "net_driver":"ixgbe","hugepage":"2048M" (indicating that the ixgbe driver needs to be loaded and 2GB of large page memory is reserved).

[0032] Furthermore, to improve system fault tolerance, if the corresponding feature profile cannot be found based on the hardware identification information (e.g., an unknown new device ID is identified), the system can also be configured to load a "DefaultSafeProfile". This default file only contains the basic configurations required to maintain the system's minimal operation (e.g., only enabling the debug serial port and not initializing the network card), so that developers can troubleshoot and prevent the system from hanging directly due to the inability to find the configuration.

[0033] In some examples, this application determines the target device model based on hardware identification information; according to the target device model, it locates and loads the feature configuration file uniquely corresponding to the target device model in the device feature configuration library. Specifically, this approach introduces "device model" as an intermediate logical layer. In actual production, the same device model (e.g., "enterprise gateway-A") may have different hardware IDs due to different production batches (e.g., the ID for PCBV1.0 is HW_Rev_1.0, and the ID for PCBV1.1 is HW_Rev_1.1), but the underlying driver configurations they require are completely consistent. By first mapping to the device model and then to the feature configuration file, this application's embodiments achieve flexible "many-to-one" matching. That is, multiple different hardware identification information can point to the same target device model, and thus share the same feature configuration file. For example, the mapping table can define: Hardware ID 0x1001 -> mapped to -> Device model Model_A; Hardware ID 0x1002 -> mapped to -> Device model Model_A; Device model Model_A -> corresponding file -> config_model_A.json.

[0034] The advantage of doing this is that it avoids copying an identical configuration file for every minor hardware version difference (as long as it does not affect the driver logic), greatly reducing the redundancy of the configuration library and making it easier for R&D personnel to perform unified version management and maintenance for the same model of device.

[0035] In some examples, before initializing the target device according to the feature profile, the method also includes: establishing a general hardware abstraction layer for parsing the feature profile, the general hardware abstraction layer having a pre-built unified functional interface covering system resource allocation, network card initialization, indicator light control, bypass switch control and processor temperature monitoring functions.

[0036] Specifically, the General Hardware Abstraction Layer (HAL) is a middleware layer located between the operating system kernel and the upper-layer application. Its core design principle is "separation of interface and implementation." During the construction phase, this application predefines a set of standardized function pointer structures or abstract base classes as the unified functional interface for the General Hardware Abstraction Layer. The definitions of these unified functional interfaces are fixed and do not change with different device models.

[0037] For example, the unified functional interface includes, but is not limited to, the following definitions: Indicator light control interface: Defines a standard function such as `int hal_led_set(int led_id, int status)`. Regardless of whether the underlying layer controls GPIO level toggling or writes to registers of the expansion chip via I2C, the upper-layer application only needs to call this unified function, passing in the lamp number and status.

[0038] Bypass switch control interface: Defines standard functions such as int hal_bypass_switch(int pair_id, intaction). This interface hides the physical differences of relay circuits (such as normally open or normally closed), exposing only the logical semantics of "on" or "off".

[0039] Network interface initialization interface: Defines a standard function such as int hal_nic_init(char* driver_name, int port_map[]). This interface is used to uniformly handle the loading of network interface drivers (insmod), renaming of network ports (renaming), and setting of interrupt affinity (IRQ affinity).

[0040] System resources and monitoring interface: Defines standard functions such as int hal_get_cpu_temp() and int hal_alloc_hugepage(int size).

[0041] Understandably, during the "establishment" phase before initialization, these unified functional interfaces are in an "unbound" or "null" state. In other words, the system merely loads the HAL framework code segment into memory and reserves "slots" (Hooks) for mounting underlying drivers, but these slots are not yet connected to specific hardware driver functions. This lays the architectural groundwork for subsequent "dynamic binding" based on configuration files.

[0042] By pre-setting a unified interface layer that covers all business scenarios (resources, network cards, peripherals, monitoring), this application realizes "write once, run anywhere" for business logic code, decoupling the upper-layer software from the physical distribution of the underlying hardware.

[0043] In some examples, the target device is initialized based on the feature configuration file, including: parsing the feature configuration file through the general hardware abstraction layer to extract the hardware physical parameters of the target device; dynamically binding the unified function interface to the underlying hardware driver function or physical register address corresponding to the target device based on the hardware physical parameters; and calling the dynamically bound unified function interface to perform system resource allocation and hardware component parameter configuration for the target device.

[0044] Specifically, firstly, during the parsing phase, the General Hardware Abstraction Layer (GHIB) calls a pre-built parser (such as JSONParser) to read key-value pairs from the feature configuration file. For example, it extracts the current device's LED control mode as type: gpio and pin parameter as pin: 50 from the configuration file; or it extracts the BYPASS control mode as type: register and address parameter as addr: 0x300.

[0045] Secondly, during the dynamic binding phase, the general hardware abstraction layer (HAL layer) maintains a set of function pointers or operation handles, which correspond to the aforementioned "unified functional interface".

[0046] Scenario 1: Binding to the underlying hardware driver function. When the configuration is resolved to "standard driver mode" (such as GPIO), the HAL layer will point the function pointer of the unified interface (e.g., hal_led_set_ptr) to the entry point of the standard driver function provided by the operating system kernel (e.g., the address of the sysfs_gpio_set_value function). At this time, a mapping is established between the unified interface and the standard driver.

[0047] Scenario 2: Binding to Physical Register Address When the configuration is resolved to "register direct drive mode" (such as a custom FPGA / CPLD circuit), the HAL layer first maps the physical address (e.g., 0x300) defined in the configuration file to a virtual address in user space via memory mapping (mmap). Then, the HAL layer points the function pointer of the unified interface to a general operation function specifically for register reading and writing (e.g., mmio_write_func), and binds the mapped address as the parameter context.

[0048] Finally, this binding is completed during the execution phase. When the system needs to allocate resources (such as allocating large page memory) or configure parameters (such as lighting up LEDs), the main control program only needs to call the already bound unified function interface.

[0049] For example, the main control program executes hal_led_set(ON).

[0050] If on device A (which is already bound to GPIO), the call will eventually execute "write 1 to GPIO 50".

[0051] If on device B (which is already bound to a register), the call will ultimately execute "write 0xFF to address 0x300".

[0052] In this way, the upper-level calling logic remains completely consistent, while the lower-level execution path undergoes a "seamless switch" depending on the configuration file.

[0053] In some examples, a unified hardware operation interface is generated based on the feature configuration file, allowing upper-layer applications to control the hardware components of the target device through the hardware operation interface. This includes: parsing the feature configuration file to extract the mapping relationship between the business control logic of the hardware components and the underlying physical parameters; calling the general hardware abstraction layer, and based on the mapping relationship, encapsulating the driver operations for the underlying physical parameters into standardized business control instructions, and exporting the standardized business control instructions to generate the hardware operation interface.

[0054] Specifically, firstly, the system identifies the correspondence between business intents and physical implementations from the feature configuration file. Business control logic refers to the functional descriptions that upper-layer applications are concerned with, such as "System_Alarm_LED" or "Optical_Bypass_Mode".

[0055] The underlying physical parameters are the hardware details required to implement this function, such as "GPIO_Pin_12" or "Register_0x40_Bit_3". The system establishes a dynamic mapping table, for example, recording: CMD_SET_ALARM -> GPIO_12.

[0056] Secondly, this application's embodiments adopt the design concept of the Command Pattern. The general hardware abstraction layer instantiates a series of standardized business control instruction objects. These objects have a unified name externally (such as bypass_enable), but their internal execution logic (Payload) is dynamically filled according to the aforementioned mapping relationship.

[0057] For example, the standardized instruction to "enable bypass" is encapsulated as a call to gpio_set_value(50, 1) on device A, while on device B it is encapsulated as a call to i2c_write(0x20, 0x01). This encapsulation process is completed dynamically in memory and is transparent to the upper layers.

[0058] Finally, regarding the "Export and Generate" steps: To enable upper-layer applications or operations and maintenance personnel to use these encapsulated commands, the system exports them as callable interfaces, primarily in two forms: Generating a command-line tool (CLI): Based on the parsing results, the system dynamically registers system commands or generates script files (such as bypass_cli.py). This tool provides standard parameter options (such as --status on / off). When the user executes bypass_cli --statuson, the tool automatically looks up the mapping table and translates the logical command into a low-level driver call specific to the current device hardware. This means that operations and maintenance personnel can use the exact same scripts and commands when maintaining different models of devices, without needing to remember complex hardware differences.

[0059] Generate Application Programming Interface (API): The system exposes a set of standard function symbols (such as api_set_bypass()) through shared memory, dynamic link libraries (.so), or inter-process communication (IPC) mechanisms. Upper-layer business programs (such as firewall software) only need to link this library to control the hardware, without needing to know whether the underlying layer is GPIO or registers.

[0060] Through the above mechanism, this application successfully constructed an isolation layer between "business requirements" and "hardware implementation", so that the development and porting of upper-layer software are no longer limited by specific hardware platforms.

[0061] According to the solution provided in this application embodiment, during the system startup phase of the target device, the hardware identification information of the target device is read; based on the hardware identification information, the corresponding feature configuration file of the target device is called from the preset device feature configuration library; the target device is initialized according to the feature configuration file, and a unified hardware operation interface is generated according to the feature configuration file, so that the upper layer application can control the hardware components of the target device through the hardware operation interface; it has the following effects: 1. Achieving "one-time development, multi-device adaptation" significantly reduces R&D and maintenance costs. By "reading hardware identification information" and "calling the corresponding feature configuration file," this application successfully decouples the physical differences of the underlying hardware (such as different GPIO pins and different network card slots) from the upper-layer software logic. This means that manufacturers only need to maintain one universal operating system image (firmware image) to adapt to various different hardware devices (such as devices A, B, and C). Compared to the existing technology that requires maintaining a separate set of driver code for each device ("one code per device"), this application greatly eliminates code redundancy and reduces the software maintenance workload for multiple product lines by more than 50%.

[0062] 2. By shielding the underlying hardware differences and improving the portability and versatility of upper-layer applications, this application constructs a dynamic adaptation barrier between the business application layer and the underlying hardware by "generating a unified hardware operation interface based on feature configuration files." Upper-layer applications (such as firewall software and routing protocol stacks) do not need to concern themselves with specific hardware details (e.g., whether an LED is connected to a GPIO or a register); they only need to call the uniformly generated interface to complete the control. This enables seamless migration of business software across different hardware platforms, greatly reducing the complexity of software porting.

[0063] 3. Supports rapid hardware expansion with "zero code modification," accelerating product iteration cycles. When new device models need support, technicians do not need to modify the core source code or recompile the system kernel. They only need to add a configuration file (such as a JSON file) describing the physical parameters of the device to the "pre-built device feature configuration library," and the system can automatically recognize and adapt upon the next startup. This data-driven architecture shortens the adaptation cycle for new hardware from "weekly" to "hourly."

[0064] 4. Eliminating the "blind state" risk during system startup and improving device reliability: By actively reading hardware identifiers and performing targeted initialization during the "system startup phase," this application avoids the risk of misoperation that may occur when general software runs on unknown hardware (e.g., avoiding mistaking the reset pin for an LED pin). It ensures that system resources (such as large page memory and network card drivers) are precisely configured according to the physical characteristics of the current hardware, thereby improving the success rate of system startup and the stability of operation.

[0065] To better understand this application, this embodiment provides a more specific example for illustration.

[0066] like Figure 2As shown, in step 1: when the system starts up, the hardware detection process reads the system DMI information ( / sys / class / dmi / id / modalias) and parses it to determine the current device model, for example, the current device model is: Device A; Step 2: Based on the device model A determined in Step 1, read and load the feature configuration file of device model A, and enter the initialization of each functional module (system resource configuration, network card initialization module, bypass control module, LED control module, etc.); Step 3: Enter the system resource configuration module, and allocate system CPU, allocate large-leaf memory, and install dependent drivers according to the feature configuration file (sys_config.json) loaded in Step 2; Step 4: After completing Step 3, enter the network card initialization module and perform binding and initialization operations according to the feature configuration file (network_config.json) loaded in Step 2; Step 5: After completing Step 4, enter the BYPASS control module. Based on the feature configuration file (bypass_config.json) loaded in Step 2, provide unified CLI commands to the outside world, which can be used to perform command operations such as enabling and disabling BYPASS and querying the interface. Step 6: After completing Step 5, enter the LED control module. Based on the feature configuration file (led_config.json) loaded in Step 2, provide unified CLI commands to the outside world, which can be used to perform command operations such as switching the LED lights on and off and blinking. Once the above steps are completed, the entire adaptation initialization process is finished.

[0067] This invention significantly improves the efficiency and reliability of underlying function adaptation for multiple network device models by constructing a three-layer architecture of "automatic device identification + feature configuration library + general hardware abstraction layer". The specific technical effects are as follows: It significantly improves development and maintenance efficiency, eliminating the need to write repetitive code for each device, such as system resource configuration, network card initialization, LED control, and BYPASS control logic. Only one set of general core logic and multiple lightweight configuration files need to be maintained, reducing the development cycle by more than 50%.

[0068] To achieve true "develop once, deploy on multiple devices", the same set of components can run on multiple hardware platforms such as devices A, B, and C. The system automatically loads the corresponding configuration according to the actual device type, avoiding compatibility errors caused by hard coding.

[0069] Enhance system stability and robustness by using configuration drivers instead of conditional compilation or macro definition switching logic to reduce human error; all hardware operations are verified through a unified interface to reduce the risk of misoperation (such as erroneous operation BYPASS).

[0070] It supports flexible expansion and rapid product iteration. When adding a new device model, you only need to add its feature configuration file. There is no need to modify the main control program or recompile the firmware, which greatly simplifies the product line expansion process.

[0071] Unified management covering key hardware functions brings together previously scattered and heterogeneous hardware controls (such as settings for different LED registers and control logic for different BYPASS circuits) into a unified framework, facilitating monitoring and logging.

[0072] All of the above-mentioned optional technical solutions can be combined in any way to form the optional embodiments of this application, and will not be described in detail here.

[0073] Based on the same concept, this application also provides a device configuration apparatus, such as... Figure 3 As shown, the configuration device of the equipment includes: The reading module 301 is used to read the hardware identification information of the target device during the system startup phase of the target device; Feature module 302 is used to call the feature configuration file corresponding to the target device from the preset device feature configuration library according to the hardware identification information; The configuration module 303 is used to initialize the target device according to the feature configuration file and generate a unified hardware operation interface according to the feature configuration file, so that the upper layer application can control the hardware components of the target device through the hardware operation interface.

[0074] In some examples, hardware identification information includes at least one of the following: device model number, PCIe device identifier, system management BIOS information, and a specific general purpose input / output level combination; reading the hardware identification information of the target device includes: reading the non-volatile memory of the target device, accessing the system hardware interface, or detecting the hardware pin status to obtain the hardware identification information.

[0075] In some examples, based on hardware identification information, the feature configuration file corresponding to the target device is called from a pre-set device feature configuration library. This includes: determining the target device model based on the hardware identification information; and locating and loading the feature configuration file that uniquely corresponds to the target device model in the device feature configuration library based on the target device model.

[0076] In some examples, before initializing the target device according to the feature profile, the method also includes: establishing a general hardware abstraction layer for parsing the feature profile, the general hardware abstraction layer having a pre-built unified functional interface covering system resource allocation, network card initialization, indicator light control, bypass switch control and processor temperature monitoring functions.

[0077] In some examples, the target device is initialized based on the feature configuration file, including: parsing the feature configuration file through the general hardware abstraction layer to extract the hardware physical parameters of the target device; dynamically binding the unified function interface to the underlying hardware driver function or physical register address corresponding to the target device based on the hardware physical parameters; and calling the dynamically bound unified function interface to perform system resource allocation and hardware component parameter configuration for the target device.

[0078] In some examples, a unified hardware operation interface is generated based on the feature configuration file, allowing upper-layer applications to control the hardware components of the target device through the hardware operation interface. This includes: parsing the feature configuration file to extract the mapping relationship between the business control logic of the hardware components and the underlying physical parameters; calling the general hardware abstraction layer, and based on the mapping relationship, encapsulating the driver operations for the underlying physical parameters into standardized business control instructions, and exporting the standardized business control instructions to generate the hardware operation interface.

[0079] According to the solution provided in this application embodiment, during the system startup phase of the target device, the device reads the hardware identification information of the target device; based on the hardware identification information, it calls the corresponding feature configuration file of the target device from a pre-set device feature configuration library; it initializes the target device according to the feature configuration file, and generates a unified hardware operation interface based on the feature configuration file, so that the upper-layer application can control the hardware components of the target device through the hardware operation interface. This application achieves complete decoupling between the upper-layer business software and the underlying hardware platform by automatically identifying the hardware identifier and loading the matching feature configuration file during the system startup phase, and dynamically constructing a unified hardware operation interface. This solution solves the code fragmentation problem of the traditional "one machine, one code" model, enabling rapid adaptation and "zero-code" expansion of multiple device models without modifying the core code, significantly improving code reusability and system portability, avoiding the problems of high code duplication and low code reusability in software development, and shielding underlying physical differences through a unified interface, effectively avoiding the risk of misoperation during the startup phase and ensuring the reliability of device operation.

[0080] Figure 4 This is a schematic diagram of the electronic device 4 provided in an embodiment of this application. Figure 4As shown, the electronic device 4 of this embodiment includes: a processor 401, a memory 402, and a computer program 403 stored in the memory 402 and executable on the processor 401. When the processor 401 executes the computer program 403, it implements the steps in the various method embodiments described above. Alternatively, when the processor 401 executes the computer program 403, it implements the functions of each module / unit in the configuration device embodiments of the various devices described above.

[0081] Electronic device 4 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 4 may include, but is not limited to, processor 401 and memory 402. Those skilled in the art will understand that... Figure 4 This is merely an example of electronic device 4 and does not constitute a limitation on electronic device 4. It may include more or fewer components than shown, or different components.

[0082] The processor 401 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0083] The memory 402 can be an internal storage unit of the electronic device 4, such as a hard disk or RAM of the electronic device 4. The memory 402 can also be an external storage device of the electronic device 4, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc., equipped on the electronic device 4. The memory 402 can also include both internal and external storage units of the electronic device 4. The memory 402 is used to store computer programs and other programs and data required by the electronic device.

[0084] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device's configuration unit can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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.

[0085] If an integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium may include: any entity or device capable of carrying computer program code, a configuration device, recording medium, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to regional requirements and patent practice requirements. For example, in some regions, according to regional requirements and patent practice, the computer-readable medium does not include electrical carrier signals and telecommunication signals.

[0086] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for configuring a device, characterized in that, The method includes: During the system startup phase of the target device, the hardware identification information of the target device is read; Based on the hardware identification information, the feature configuration file corresponding to the target device is retrieved from the preset device feature configuration library; The target device is initialized according to the feature configuration file, and a unified hardware operation interface is generated according to the feature configuration file, so that upper-layer applications can control the hardware components of the target device through the hardware operation interface.

2. The method according to claim 1, characterized in that, The hardware identification information includes at least one of the following: device model number, PCIe device identifier, system management BIOS information, and a specific general purpose input / output level combination; reading the hardware identification information of the target device includes: The hardware identification information is obtained by reading the non-volatile memory of the target device, accessing the system hardware interface, or detecting the hardware pin status.

3. The method according to claim 1, characterized in that, Based on the hardware identification information, the feature configuration file corresponding to the target device is retrieved from the preset device feature configuration library, including: Based on the hardware identification information, the target device model corresponding to the target device is determined; Based on the target device model, locate and load the feature configuration file that uniquely corresponds to the target device model in the device feature configuration library.

4. The method according to claim 1, characterized in that, Before initializing the target device according to the feature configuration file, the method further includes: A general hardware abstraction layer is established for parsing the feature configuration file. The general hardware abstraction layer is pre-configured with a unified functional interface covering system resource allocation, network card initialization, indicator light control, bypass switch control and processor temperature monitoring.

5. The method according to claim 4, characterized in that, Initializing the target device according to the feature configuration file includes: The feature configuration file is parsed through the general hardware abstraction layer to extract the hardware physical parameters of the target device; Based on the hardware physical parameters, the unified function interface is dynamically bound to the underlying hardware driver function or physical register address corresponding to the target device; The unified function interface after dynamic binding is invoked to perform system resource allocation and hardware component parameter configuration for the target device.

6. The method according to claim 4, characterized in that, A unified hardware operation interface is generated based on the feature configuration file, allowing upper-layer applications to control the hardware components of the target device through the hardware operation interface, including: Parse the feature configuration file to extract the mapping relationship between the business control logic of the hardware component and the underlying physical parameters; The general hardware abstraction layer is invoked, and based on the mapping relationship, the driver operation for the underlying physical parameters is encapsulated into standardized business control instructions, and the standardized business control instructions are exported to generate the hardware operation interface.

7. A device configuration apparatus, characterized in that, The device includes: The reading module is used to read the hardware identification information of the target device during the system startup phase of the target device; The feature module is used to call the feature configuration file corresponding to the target device from a preset device feature configuration library based on the hardware identification information; The configuration module is used to initialize the target device according to the feature configuration file and generate a unified hardware operation interface according to the feature configuration file, so that upper-layer applications can control the hardware components of the target device through the hardware operation interface.

8. The apparatus according to claim 7, characterized in that, The hardware identification information includes at least one of the following: device model number, PCIe device identifier, system management BIOS information, and a specific general purpose input / output level combination; reading the hardware identification information of the target device includes: The hardware identification information is obtained by reading the non-volatile memory of the target device, accessing the system hardware interface, or detecting the hardware pin status.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 6.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 6.

Images