Request processing method, storage medium, electronic device and program product

Abstract

The present application discloses a request processing method, storage medium, electronic device, and program product, which relate to the field of computer technology. First, a configuration file corresponding to a target device is obtained, and the configuration file includes configuration data corresponding to different functional modules. Then, a data processing request sent by the functional module is received through a request processing interface, and the request processing interface is used to queue and process the data processing request. Finally, the request processing interface is used to determine the target data corresponding to the data processing request from the configuration data, and the target data is used to configure the function of the functional module. Compared with the current existing technology, the present application can use the request processing interface to queue the data processing requests sent by the received functional module, and then determine the target data of the data processing request from the configuration data, so that multiple data processing requests can be processed in sequence, avoiding bus contention.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular to a request processing method, a storage medium, an electronic device, and a program product. Background Art

[0002] In a baseboard management controller (BMC) system architecture, access to memory by various functional modules is clearly discrete.

[0003] Currently, in related technologies, the memory can be connected to the BMC via the Inter-Integrated Circuit (I2C) bus. When multiple functional modules try to access data in the memory at the same time, bus contention is easily caused. Summary of the Invention

[0004] The present disclosure provides a request processing method, storage medium, electronic device, and program product. The main purpose is to solve the problem of bus contention that can easily occur when multiple functional modules attempt to access data in the memory simultaneously. A memory can be connected to a BMC via a synchronous serial communication protocol bus.

[0005] In a first aspect, the present application provides a request processing method, comprising:

[0006] Obtain the configuration file corresponding to the target device, which includes configuration data corresponding to different functional modules;

[0007] Receive data processing requests sent by the functional module through the request processing interface, which is used to queue and process data processing requests;

[0008] The request processing interface is used to determine the target data corresponding to the data processing request from the configuration data, and the target data is used to perform functional configuration of the functional module.

[0009] In a second aspect, the present application provides a request processing device, comprising:

[0010] An acquisition module is configured to acquire a configuration file corresponding to a target device, where the configuration file includes configuration data corresponding to different functional modules;

[0011] a receiving module configured to receive data processing requests sent by the functional module through a request processing interface, wherein the request processing interface is used to queue and process the data processing requests;

[0012] The determination module is configured to use the request processing interface to determine the target data corresponding to the data processing request from the configuration data, and the target data is used to perform function configuration of the function module.

[0013] In a third aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which implements the method of the first aspect when the computer program is executed by a processor.

[0014] In a fourth aspect, the present application provides an electronic device comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor implements the method of the first aspect when executing the computer program.

[0015] In a fifth aspect, the present application provides a computer program product having a computer program stored thereon, which implements the method of the first aspect when the computer program is executed by a processor.

[0016] The present disclosure provides a request processing method, storage medium, electronic device and program product, wherein the method includes: first obtaining a configuration file corresponding to a target device, the configuration file including configuration data corresponding to different functional modules; then receiving a data processing request sent by a functional module through a request processing interface, the request processing interface being used to queue and process the data processing request; finally, using the request processing interface, determining target data corresponding to the data processing request from the configuration data, the target data being used to perform functional configuration of the functional module. Compared with the current prior art, the present application can first determine a configuration file matching the target device, store the configuration data required by different functional modules through the configuration file, then use the request processing interface to queue the data processing request sent by the received functional module, and then determine the target data of the data processing request from the configuration data, so that multiple data processing requests can be processed in sequence, avoiding bus contention, and thereby ensuring the processing efficiency of the data processing request.

[0017] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present application, nor is it intended to limit the scope of the present application. Other features of the present application will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0019] Figure 1 A schematic diagram of a request processing method provided in an embodiment of the present application is shown;

[0020] Figure 2 A schematic diagram showing a flow chart of another request processing method provided in an embodiment of the present application is shown;

[0021] Figure 3 A schematic diagram showing an example provided by an embodiment of the present application is shown;

[0022] Figure 4 A schematic structural diagram of a request processing device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0023] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0024] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0025] Serial Electrically Erasable Programmable Read-Only Memory (EEPROM) chips are a common feature in server BMC boards. As non-volatile memory, EEPROM connects to the BMC controller chip via the I2C bus. It serves the crucial task of persistently storing key device characteristics. It can be used to store information such as the BMC's MAC address, the server's Universally Unique Identifier (UUID), and the server's cooling strategy. All this data can be organized in raw binary format.

[0026] In the related art, in the BMC system architecture, the access of each functional module to the EEPROM shows obvious discrete characteristics. Each functional module directly accesses the EEPROM through the I2C driver and operates the original binary data on the EEPROM. For example, taking the thermal management module and the asset management module as examples, the thermal management module will directly access the EEPROM to maintain the thermal strategy, and the asset management module will directly operate the EEPROM to manage the UUID.

[0027] This decentralized access mechanism raises a series of problems:

[0028] (1) Code redundancy and maintenance difficulties: Each functional module needs to handle the calculation of storage offsets and byte order conversion on its own, which results in a large amount of duplicate content in the code. This not only increases the amount of code but also makes subsequent maintenance difficult. Once the relevant functions need to be modified, adjustments must be made in multiple modules, which makes it easy to make mistakes.

[0029] Specifically, EEPROMs typically provide two operational interfaces: one for sending read and write commands through ioctl functions, and the other for exporting the EEPROM as a file to sysfs for read and write operations like a regular file. When each module independently operates the EEPROM, it must determine and select which interface to use at multiple points, which undoubtedly increases code complexity.

[0030] At the same time, each module independently maintains the offset and size information of the configuration items in the EEPROM, which makes the management of the storage area confusing. For example, the configuration items of module A and module B may overlap in the storage area. This overlap can cause unexpected changes in data and affect the normal operation of the system.

[0031] In addition, the offset and size of configuration items in the EEPROM of different models vary. In order to adapt to different models, different modules need to introduce model judgment logic and select the corresponding offset, size, and data parsing method accordingly. These additional judgment and processing logics greatly increase the amount of code and make code maintenance more difficult.

[0032] (2) Bus contention risk: When multiple modules attempt to access the EEPROM at the same time, bus contention can easily occur. For example, during parallel erase or write operations, hardware bus deadlock may occur, leading to system failure. This happens because the EEPROM only allows one module to operate at a time. If a module has not yet completed its operation on the EEPROM, and other modules initiate operation requests at this time, the operation will fail. To solve this problem, each module has to implement a retry mechanism on its own. However, this approach has obvious drawbacks. Modules with high frequency of access may occupy the storage device for a long time, causing the operation requests of other modules to be in a waiting state for a long time, seriously affecting the overall operating efficiency of the system.

[0033] (3) Security risks: Each module is responsible for setting the configuration items in the EEPROM. The security measures adopted lack consistency, and it is difficult to unify the security measures adopted by each module. After reading the data, some modules only verify whether the data is within a reasonable range, but ignore whether the data has been bit-flipped; while other modules only focus on whether the data has been bit-flipped, but do not consider the rationality of the data; there are even some modules that do not perform data verification at all. This fragmentation of security measures poses a major risk to the system in terms of data security and cannot effectively guarantee the integrity and accuracy of the data.

[0034] In order to improve the current related technology, the memory can be connected to the BMC by means of a synchronous serial communication protocol bus. When multiple functional modules try to access data in the memory at the same time, it is easy to cause a technical problem of bus contention.

[0035] This embodiment provides a request processing method, such as Figure 1 As shown, the method comprises the following steps:

[0036] Step 101: Obtain a configuration file corresponding to a target device, where the configuration file includes configuration data corresponding to different functional modules.

[0037] In some embodiments, the execution entity of this embodiment may be a server, etc., equipped with a BMC and various functional modules. Specifically, different server models have different EEPROM configurations. The target device may be the selected device for functional configuration. To select the appropriate configuration file based on the different models, the configuration data may include, but is not limited to, the MAC address and the UUID of the entire server. For example, the configuration data required by multiple different functional modules can be written into a single configuration file, eliminating the need to store configuration data for each module separately in multiple configuration files. This reduces the amount of code and eases system maintenance.

[0038] Step 102: Receive a data processing request sent by a functional module through a request processing interface, where the request processing interface is used to queue the data processing request.

[0039] In some embodiments, data processing requests may include but are not limited to configuration requests, data read and write requests, etc. sent by various functional modules. Specifically, each functional module may send a data processing request to the request processing interface of the BMC through its own process to obtain the required configuration data. The request processing interface can be used to queue and process multiple received data processing requests, such as the DBUS interface. The DBUS interface can be used for inter-process communication. Other processes implement read and write operations on EEPROM configuration items by calling these interfaces. DBUS is designed based on the bus model and implements inter-process collaboration through concepts such as objects, interfaces, and attributes. For example, if the current request processing interface is processing a data processing request sent by a functional module and receives other data processing requests sent by other functional modules at the same time, the other data processing requests can be queued according to the request time and processed in sequence. By queuing each request, it is effectively avoided that multiple processes compete for the bus at the same time, thereby avoiding hardware bus deadlock and improving system stability.

[0040] Accordingly, the request processing interface may include different interfaces provided for different functional modules, such as a RAV interface, a Pretty interface, etc. For example, the RAV interface may be used to receive requests sent by the Intelligent Platform Management Interface (IPMI), and the Pretty interface may be used to receive requests sent by functional modules and Bmcweb respectively.

[0041] Step 103: Using the request processing interface, determine the target data corresponding to the data processing request from the configuration data.

[0042] In some embodiments, a preset handler can be configured in the BMC. The preset handler provides a request processing interface to the outside world and is responsible for uniformly processing the configuration items in the EEPROM, so that the request processing interface determines the currently processed data processing request based on the request time of each data processing request and the idle state of the interface itself, realizes inter-process communication, and then uses the target data corresponding to the data processing request to be determined from the configuration data. The target data can be the configuration data that each functional module needs to perform read and write operations, and can be used to perform functional configuration of the functional module. In this way, the data processing requests sent by different functional modules can be processed in sequence, so that different functional modules can access the configuration data in the EEPROM in sequence, determine the target data required by each functional module for functional configuration, and each functional module does not need to access the EEPROM in a distributed manner, which reduces the amount of code of the distributed architecture of the functional modules, reduces the difficulty of system maintenance, and effectively improves the system stability.

[0043] Compared with the current existing technology, this embodiment first obtains the configuration file corresponding to the target device, and the configuration file includes configuration data corresponding to different functional modules; then receives the data processing request sent by the functional module through the request processing interface, and the request processing interface is used to queue and process the data processing request; finally, the request processing interface is used to determine the target data corresponding to the data processing request from the configuration data, and the target data is used to perform functional configuration of the functional module. Compared with the current existing technology, this application can first determine the configuration file that matches the target device, store the configuration data required by different functional modules through the configuration file, and then use the request processing interface to queue the data processing request sent by the received functional module, and then determine the target data of the data processing request from the configuration data, so that multiple data processing requests can be processed in sequence, avoiding bus contention, and thus ensuring the processing efficiency of data processing requests.

[0044] In order to further illustrate the specific implementation process of the method of this embodiment, this embodiment provides the following Figure 2 The specific method shown includes:

[0045] Step 201: Determine a configuration file corresponding to the target device based on the device information of the target device.

[0046] In some embodiments, device information may include, but is not limited to, the device model. Different server models may have different EEPROM configurations. Systemd, the Linux initialization system, can be used to select appropriate configuration files for different server models to accommodate their functional configurations. Systemd manages the startup of processes (such as cooling processes, IPMI processes, and Web processes). Systemd service unit configuration files (such as service files) can be used to define how these processes are started.

[0047] Exemplarily, the content of the service file of the EEPROM-manager may include, but is not limited to, basic information of the service, definition of the service's behavior, installation, and service activation-related settings. Specifically, in the service file, you can define ExecStartPre, which can be used to point to the script EEPROM-config-select.sh. The function of this script is to obtain model information through FRU (Field Replaceable Unit), and then find the EEPROM configuration file that matches the model, and soft link it to the preset storage location, for example: / etc / default / EEPROM.json. You can also define ExecStart, which can be used to point to EEPROM-manager, and you can use preset parameters (such as -c) to specify the configuration file to be loaded, which points to / etc / default / EEPROM.json. The specific execution steps are as follows:

[0048] (1) Start the service: systemd starts EEPROM-manager.service;

[0049] (2) Script execution: EEPROM-config-select.sh script is executed;

[0050] (3) Get the model and search for the configuration file: The script obtains the model name through the ipmitool fru command, and then searches for the configuration file that matches the model name in the / usr / share / EEPROM-manager folder;

[0051] (4) Process the search results: If a matching configuration file is found, soft link it to / etc / default / EEPROM.json; if no matching configuration file is found, the script will record a log and prompt "No configuration file for the corresponding model was found", then continue to search for the common-layout.json file in the / usr / share / EEPROM-manager folder and soft link it to / etc / default / EEPROM.json;

[0052] (5) Start the management program: After the EEPROM-config-select.sh script is executed, exit, and then call EEPROM-manager -c / etc / default / EEPROM.json. The -c parameter specifies that the configuration file to be loaded is / etc / default / EEPROM.json.

[0053] In this way, it can be ensured that servers of different models can use the EEPROM configuration files adapted to them, thus improving the compatibility and maintainability of the system.

[0054] Step 202: Obtain the configuration items corresponding to the functional modules, and perform interval detection on the storage intervals of the configuration items in the configuration file.

[0055] In some embodiments, the EEPROM management module can automatically identify the model and configuration file. By parsing the configuration file, the management module can accurately determine the EEPROM configuration information corresponding to the current model.

[0056] Accordingly, if there are multiple configuration items in the configuration file, it is necessary to perform interval detection on the multiple configuration items and perform overlap verification on the storage areas of the configuration items to ensure that the storage locations of the configuration items in the EEPROM do not conflict with each other.

[0057] In some embodiments, performing interval detection on the storage intervals of the configuration items in the configuration file may specifically include: detecting whether the storage intervals of different configuration items overlap based on the start offsets and end offsets corresponding to the different configuration items.

[0058] For example, when loading a configuration file, the system automatically detects the storage intervals of each configuration item in the EEPROM and performs configuration interval overlap verification on all configuration items. The starting offset (starting position) of each configuration item can be the offset of the configuration item in the EEPROM, and the ending offset (ending position) can be determined based on the starting offset and the space occupied by the configuration item.

[0059] Optionally, based on the starting offsets and ending offsets corresponding to different configuration items, detecting whether the storage intervals of different configuration items overlap may specifically include: obtaining a target configuration item to be detected from the configuration items, and other configuration items in the configuration items except the target configuration item; comparing the starting offset of the target configuration item with the ending offsets of other configuration items; and determining, based on the comparison result, whether the storage interval of the target configuration item overlaps with the storage intervals of other configuration items.

[0060] In some embodiments, when a configuration file contains multiple configuration items, the system will perform an overlap check on each field. The specific verification method is as follows: For each configuration item, the system will generate a key-value pair containing a starting position (start) and an ending position (end), where the start value is the offset of the configuration item in the EEPROM, and the end value is the offset plus the size of the space occupied by the configuration item (offset + size). After generating the key-value pair, the system will sort them in order from the smallest to the largest start value. After the sorting is completed, the system checks each configuration item in turn. If it is found that the start field value of a configuration item is less than the end field value of a previous configuration item, it is determined that there is an overlap between the configuration items. If an overlap is detected, the EEPROM-manager program will immediately exit abnormally and stop providing the dbus interface to the outside world. This prevents data confusion and system failures caused by overlapping configuration items, ensuring the stability of system operation and the accuracy of data.

[0061] For each configuration item, a key-value pair consisting of a start offset and an end offset is generated. The start offset values ​​are sorted from smallest to largest and then checked in sequence. If the start offset of a configuration item is found to be smaller than the end offset of the previous configuration item, it is determined that there is an interval overlap.

[0062] Step 203: Load a configuration file according to the interval detection result of the storage interval, where the configuration file includes configuration data corresponding to different functional modules.

[0063] Optionally, when loading a configuration file, the system performs a series of rigorous checks, such as checking whether the configuration file is empty and the number of configuration items in the configuration file. If the configuration file is empty, the system will immediately determine that it is invalid and the EEPROM-manager program will abnormally exit to avoid system errors caused by invalid configuration. At least one configuration item can be stored in the same configuration file. If the configuration file contains only one configuration item, the system will skip the subsequent complex verification steps because there is no possibility of overlapping configuration items, thereby improving program operation efficiency.

[0064] For example, Figure 3 As shown, you can first select the configuration file to determine the configuration file corresponding to the target device, then load the configuration file, and then perform configuration verification. You can use multiple UUIDHandlers for verification.

[0065] Specifically, the EEPROM manager program loads the configuration file and retrieves the EEPROM offset (offset), size (size), handler (handler), and name (name) of each field. The configuration file's layout field lists the name, offset, size, option, handler, raw, and pretty fields in an array format. The configuration file also includes the EEPROM_path.

[0066] In some embodiments, loading a configuration file based on the interval detection result of the storage interval may specifically include: if it is detected that the storage intervals of different configuration items overlap, stopping using the request processing interface; if it is detected that the storage intervals of different configuration items do not overlap, loading the configuration file.

[0067] For example, if it is detected that the configuration items have overlapping intervals, the EEPROM-manager process exits abnormally and no longer provides the DBUS interface, preventing data confusion and system abnormalities caused by overlapping configuration intervals and ensuring stable system operation; if it is detected that the storage intervals of different configuration items do not overlap, the configuration file can be loaded for subsequent processing.

[0068] Step 204: Receive the data processing request sent by the functional module through the request processing interface.

[0069] In some embodiments, an independent EEPROM management module can be developed. This module provides centralized scheduling and management of EEPROM access and provides a DBUS interface. This allows other modules to interact with the management module via the DBUS interface, rather than directly accessing the EEPROM via the I2C bus. The management module queues all EEPROM access requests from other modules and executes them sequentially, thus avoiding contention caused by multiple modules accessing the EEPROM simultaneously and ensuring stable system operation.

[0070] By creating a dedicated independent process on the BMC to manage the EEPROM, the traditional decentralized management model of each functional module is broken. The process can use the DBUS interface to achieve inter-process communication. By taking advantage of the design advantage of DBUS based on the bus model and defining abstract concepts such as objects, interfaces and attributes, it provides a unified and convenient EEPROM access path for other functional modules, ensuring orderly data interaction between modules and avoiding a series of problems caused by direct access to the EEPROM.

[0071] Optionally, receiving a data processing request sent by a functional module through a request processing interface may specifically include: receiving a data processing request sent by a process corresponding to a different functional module through a request processing interface corresponding to the different functional modules.

[0072] Accordingly, multiple request processing interfaces can be provided for multiple different functional modules. Each request processing interface can be used to receive requests sent by at least one functional module, so as to uniformly select the operation interface for different functional modules to communicate with the EEPROM, avoiding repeated interface selection judgments by each functional module, thereby effectively reducing code redundancy and improving the maintainability of the system.

[0073] Step 205: Utilize the request processing interface to determine the target data corresponding to the data processing request from the configuration data.

[0074] Optionally, step 205 may specifically include: obtaining a configuration item corresponding to the data processing request; determining a preset configuration interface corresponding to the configuration item from the request processing interface; and determining target data corresponding to the configuration item from the configuration file using the preset configuration interface.

[0075] For example, preset configuration interfaces can be configured for different types of configuration items (MAC addresses, UUIDs, enumeration items, numerical attribute configuration items, etc.). As exclusive interfaces for each configuration item, they facilitate the calling of each functional module, allowing developers to clearly understand and operate the data in the EEPROM. This customized and highly readable DBUS interface improves the system's usability and interactivity.

[0076] Optionally, using a preset configuration interface, the target data corresponding to the configuration item is determined from the configuration file, which may specifically include: obtaining the path information corresponding to the configuration item based on the attribute information corresponding to the configuration item and the description field in the configuration file; using the preset configuration interface, determining the target data corresponding to the configuration item based on the path information.

[0077] For example, the specific contents of the preset configuration interfaces corresponding to different types of configuration items are as follows:

[0078] The DBUS interface corresponding to the MAC address can be com.otrd.Network.MAC, and the attribute name is MACAddress. The object path is generated based on the name field describing the network card in the configuration file. After the function module generates the path based on the network port name, it uses this interface to read and write the MACAddress attribute.

[0079] The interface corresponding to UUID can be designed as com.otrd.Common.UUID, with the attribute name UUID. The object path is generated based on the name field in the configuration file that describes the purpose of the UUID. When reading and writing, the UUID attribute is operated according to this path and interface.

[0080] For enumeration items, two DBUS interfaces can be configured for each item. The Pretty property of the com.otrd.EEPROM.Setting.Pretty interface is a string type that describes the meaning of the enumeration item; the RawData property of the com.otrd.EEPROM.Setting.RawData interface is a byte type that represents the specific value in the EEPROM. The object path of both interfaces is the same, generated by the name field of the enumeration item usage in the configuration file. When reading and writing enumeration items on the BMC management webpage (such as cooling policy selection), the Pretty property is manipulated using the com.otrd.EEPROM.Setting.Pretty interface; when reading and writing via IPMI, the RawData property is manipulated using the com.otrd.Setting.Rawdata interface.

[0081] The DBUS interface corresponding to the numerical attribute configuration item is com.otrd.Counter, with the attribute name Counter. The object path is generated based on the name field describing the purpose in the configuration file. The function module first determines the path and then uses the interface to read and write the Counter attribute.

[0082] Optionally, the method of this embodiment may further include: processing target data corresponding to the configuration item based on the path information according to the field type corresponding to the configuration item.

[0083] The path information may include an EEPROM path, and the EEPROM path may be obtained according to the EEPROM_path field.

[0084] Optionally, before processing the target data corresponding to the configuration item based on the path information according to the field type corresponding to the configuration item, the method of this embodiment may further include: obtaining a preset processing rule corresponding to the field type.

[0085] Optionally, according to the field type corresponding to the configuration item, the target data corresponding to the configuration item is processed based on the path information, which may specifically include: according to the data processing request, the target data corresponding to the configuration item is processed based on the path information to obtain the processed target data; if the processed target data does not meet the preset processing rules corresponding to the field type, a parameter error alarm is generated.

[0086] For example, field handlers can include multiple types, such as MacHandler, UUIDHandler, EnumHandler, and CountHandler. The processing rules for each type are as follows:

[0087] (1) MacHandler: Only accepts unicast MAC addresses. If the MAC address to be set is all 0s, or the value of its first byte is 0xB1, it is determined to be a non-unicast MAC address and a parameter error will be returned during setting. In other cases, the MAC address can be written to the EEPROM normally.

[0088] (2) UUIDHandler: If the UUID to be set is 16 bytes with values ​​all equal to 0x00, or 16 bytes with values ​​all equal to 0xff, it is determined to be an illegal UUID and a parameter error is returned during setting. In other cases, the UUID can be written to the EEPROM normally, thus enabling identification and interception of illegal UUIDs.

[0089] (3) EnumHandler: Adds a new option field to associate raw binary data with its meaning. The raw field represents the value of the data in the EEPROM, and the pretty field describes its meaning in the form of a readable string, with the two corresponding one to one.

[0090] (4) CountHandler: Only accepts data with a value range between 0 and 255. If the input value exceeds this range, a parameter error will be returned during the setting. If it is within the range, it can be written to the EEPROM normally, thus limiting the value to a specific range.

[0091] In this way, the EEPROM manager can accurately manage the data in the EEPROM according to the configuration file and ensure the legitimacy and validity of the written data. For each configuration item in the EEPROM, strict data rationality verification rules are established.

[0092] Optionally, the method of this embodiment may further specifically include: if the path information does not exist, processing the target data corresponding to the configuration item according to the bus number and the slave device address.

[0093] In some embodiments, when accessing the EEPROM, the system retrieves the EEPROM path based on the EEPROM_path field. If the path exists, the system accesses the EEPROM as a regular file. If the path does not exist, the system parses the path to obtain the I2C bus number and slave device (slave) address, and then uses ioctl to read and write the EEPROM. The parsing method is to extract the string between the second-to-last and last " / " symbols in the path. The number before the "-" symbol in the string represents the bus number, and the number after the "-" symbol represents the device's slave address (which must be converted to hexadecimal). For example, "1-0050" indicates that the EEPROM device is located on I2C bus 1 and has a slave address of 0x50.

[0094] Accordingly, when resolving the path to obtain the I2C bus number and slave device address, if the extracted string does not conform to the "number-number" format, or if the number after the "-" sign fails to convert to hexadecimal, the program will log a detailed error message stating "EEPROM path resolution failed." In this case, the system will determine the next steps based on pre-defined rules, either attempting to re-parse the path or directly terminating the operation and notifying the user to ensure reliable system operation.

[0095] Furthermore, whether accessing the EEPROM as a regular file or via ioctl, the program promptly captures any read or write errors (such as insufficient permissions or device failure). In addition to logging the error code and description, it also returns an error flag to the upper-level application. Upon receiving the error flag, the upper-level application can take appropriate action, such as prompting the user to check device connectivity and correct permissions, thereby improving system stability and user experience.

[0096] Optionally, after obtaining the processed target data, the method further includes: storing the processed target data in a cache.

[0097] Specifically, to improve data read efficiency, the EEPROM-manager can store all EEPROM configuration items in a cache after successfully reading them. Subsequently, when the system needs to read data again, it can directly obtain it from the cache without repeatedly accessing the EEPROM. This significantly shortens data read time and improves system responsiveness.

[0098] Accordingly, when the EEPROM configuration needs to be modified, the system follows a rigorous process. First, the corresponding configuration fields in the cache are updated. Next, the CRC8 algorithm is used to recalculate the checksum based on the updated configuration data, generating a new checksum field. Finally, the system writes all updated configuration items and the new checksum field to the EEPROM. This ensures that the data in the EEPROM and the cache remain consistent, effectively protecting data integrity and maintaining stable system operation.

[0099] In this way, a cache mechanism is introduced to optimize the EEPROM data reading and writing process. After successfully reading all configuration items, the data is temporarily stored in the cache. Subsequent read operations give priority to obtaining data from the cache, reducing the number of direct accesses to the EEPROM and improving data reading efficiency.

[0100] Optionally, the method of this embodiment may further include: generating a check value corresponding to the configuration item in response to powering on the device; and performing data verification on the configuration data in the configuration file using the check value.

[0101] In some embodiments, a unified security protection mechanism can be implemented within the EEPROM management module. This mechanism verifies the validity of configuration item data and whether bit flips have occurred. When reading and writing data, the management module strictly checks the data according to unified verification rules to ensure data integrity and accuracy. If any data anomalies are detected, the management module will promptly take appropriate measures, such as rejecting the write or displaying an error message, thereby effectively improving system security.

[0102] Specifically, to ensure the accuracy and integrity of EEPROM data, a checksum field is added to the end of the EEPROM layout. This checksum field is generated using the CRC8 checksum algorithm with a polynomial of 0x07. Each time the device is powered on, the system automatically reads all configuration items from the EEPROM and recalculates the checksum using the CRC8 algorithm. The newly calculated checksum is then compared with the checksum field originally stored in the EEPROM. If the two do not match, the system determines that the checksum has failed. At this point, to prevent system anomalies caused by data errors, the EEPROM-manager process immediately terminates and stops providing external DBUS interface services.

[0103] This approach uses a unified CRC checksum mechanism, employing the CRC8 checksum algorithm with a polynomial of 0x07, to verify the entire EEPROM storage space. Whether the device is powered on or after data modification, the checksum is recalculated and compared with the checksum field stored in the EEPROM. This allows for the timely detection and avoidance of errors such as bit flips, ensuring data integrity and accuracy.

[0104] As a possible implementation, Figure 3 As shown in the figure, the system architecture diagram is shown. The EEPROM-manager can be used to manage the configuration and operation of the EEPROM. The RAW interface can be used to connect to IPMI, and the Pretty interface can be used to receive data processing requests sent by functional modules and Bmcweb. Multiple Handlers can be used to process different configuration items respectively. Then, the data and structure in the EEPROM can be identified. Communication with the EEPROM can be achieved through I2C ioctl or EEPROM file (EEPROM file), and configuration data can be read and written. Among them, I2C ioctl can perform input / output control through the I2C bus for communication with the EEPROM.

[0105] This approach builds an independent EEPROM management module and uses a DBUS interface for inter-process communication, enabling orderly scheduling of EEPROM access. This approach changes the previous model of direct concurrent access by multiple modules. EEPROM access requests are queued within the management module, fundamentally eliminating bus conflicts caused by multiple modules simultaneously reading and writing to the EEPROM. This ensures stable operation of the hardware bus, avoids serious issues such as deadlock, and provides a solid foundation for stable EEPROM reading and writing by the system.

[0106] Secondly, a unified EEPROM identification and configuration detection strategy is proposed. Regarding identification, standardized identification rules are established for different types of configuration items. For example, dedicated DBUS interfaces and object path generation methods are designed for configuration items such as MAC addresses and UUIDs, enabling the system to accurately locate and manage configuration items. Configuration detection strategies cover functions such as configuration file identification, storage area overlap verification, and unified selection of operation interfaces. The implementation of these strategies avoids repeated operations such as offset calculation, byte order conversion, and interface selection judgment across modules, effectively reducing code redundancy. Furthermore, a unified and standardized management model reduces the risk of configuration errors, improves system reliability, and makes subsequent system maintenance and functional expansion more convenient and efficient.

[0107] Furthermore, a cache and CRC checksum mechanism has been introduced to improve system performance. Caching and CRC checksums are incorporated into the EEPROM read and write processes. After successfully reading all configuration items, the cache stores the data in the cache. Subsequent read operations directly retrieve data from the cache, reducing repeated accesses to the EEPROM, significantly shortening data read time, and significantly improving system data processing efficiency. The CRC checksum mechanism uses the CRC8 checksum algorithm with a polynomial of 0x07. It verifies all EEPROM configuration items upon device power-up. The checksum is recalculated and the EEPROM checksum field is updated after each data modification. This method can promptly detect data errors such as bit flips, ensure consistency between EEPROM data and cached data, effectively safeguard data integrity, and thus improve overall system reliability.

[0108] Compared with related technologies, this embodiment configures preset configuration interfaces for different types of configuration items. As exclusive interfaces for each configuration item, this facilitates the calling of each functional module, enables developers to clearly understand and operate the data in the EEPROM, improves the system's usability and interactivity, and adds a cache mechanism and a verification mechanism to reduce repeated access to the EEPROM, greatly shortens data reading time, significantly improves system data processing efficiency, and can promptly detect data errors, ensure that the configuration data is consistent with the cached data, effectively protect data integrity, and thus improve the overall reliability of the system.

[0109] The embodiment of the present application also provides a request processing device, as Figure 1 and Figure 2 The specific implementation of the method shown is as follows Figure 4 As shown, the device includes: an acquisition module 31, a receiving module 32 and a determination module 33.

[0110] An acquisition module 31 is configured to acquire a configuration file corresponding to a target device, where the configuration file includes configuration data corresponding to different functional modules;

[0111] A receiving module 32 is configured to receive a data processing request sent by a functional module through a request processing interface, wherein the request processing interface is used to queue and process the data processing request;

[0112] The determination module 33 is configured to determine target data corresponding to the data processing request from the configuration data using the request processing interface, where the target data is used to perform function configuration of the function module.

[0113] In some examples of this embodiment, the acquisition module 31 is specifically configured to determine the configuration file corresponding to the target device based on the device information of the target device; obtain the configuration item corresponding to the functional module, and perform interval detection on the storage interval of the configuration item in the configuration file; and load the configuration file based on the interval detection result of the storage interval.

[0114] In some examples of this embodiment, the acquisition module 31 is specifically configured to detect whether the storage intervals of different configuration items overlap based on the starting offsets and ending offsets corresponding to the different configuration items; and load the configuration file based on the interval detection results of the storage intervals, including: if it is detected that the storage intervals of different configuration items overlap, then stop using the request processing interface; if it is detected that the storage intervals of different configuration items do not overlap, then load the configuration file.

[0115] In some examples of this embodiment, the determination module 33 is specifically configured to obtain a target configuration item to be detected from the configuration items, as well as other configuration items in the configuration items except the target configuration item; compare the starting offset of the target configuration item with the ending offsets of the other configuration items; and determine, based on the comparison result, whether the storage interval of the target configuration item overlaps with the storage intervals of the other configuration items.

[0116] In some examples of this embodiment, the determination module 33 is specifically configured to obtain the configuration item corresponding to the data processing request; determine the preset configuration interface corresponding to the configuration item from the request processing interface; and use the preset configuration interface to determine the target data corresponding to the configuration item from the configuration file.

[0117] In some examples of this embodiment, the determination module 33 is specifically configured to obtain path information corresponding to the configuration item based on the attribute information corresponding to the configuration item and the description field in the configuration file; and use the preset configuration interface to determine the target data corresponding to the configuration item based on the path information.

[0118] In some examples of this embodiment, the determination module 33 is further configured to process the target data corresponding to the configuration item based on the path information according to the field type corresponding to the configuration item.

[0119] In some examples of this embodiment, the acquisition module 31 is further specifically configured to obtain a preset processing rule corresponding to the field type; according to the field type corresponding to the configuration item, the target data corresponding to the configuration item is processed based on the path information, including: according to the data processing request, the target data corresponding to the configuration item is processed based on the path information to obtain the processed target data; if the processed target data does not meet the preset processing rule corresponding to the field type, a parameter error alarm is generated.

[0120] In some examples of this embodiment, the acquisition module 31 is further configured to process the target data corresponding to the configuration item according to the bus number and the slave device address if the path information does not exist.

[0121] In some examples of this embodiment, the determination module 33 is further configured to store the processed target data in a cache.

[0122] In some examples of this embodiment, the determination module 33 is further configured to generate a check value corresponding to the configuration item in response to powering on the device; and perform data verification on the configuration data in the configuration file using the check value.

[0123] In some examples of this embodiment, the receiving module 32 is specifically configured to receive data processing requests sent by processes corresponding to different functional modules through request processing interfaces corresponding to different functional modules.

[0124] It should be noted that for other corresponding descriptions of the functional units involved in the request processing device provided in this embodiment, please refer to Figure 1 and Figure 2 The corresponding description in will not be repeated here.

[0125] Based on the above Figure 1 and Figure 2 The method shown in FIG. 1 is a method for performing the above-mentioned steps. Accordingly, this embodiment further provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the computer program can realize the above-mentioned steps. Figure 1 and Figure 2 The method shown.

[0126] Based on the above Figure 1 and Figure 2 The method shown in FIG. 1 is a method for performing the above-mentioned operations. Accordingly, this embodiment further provides a computer program product having a computer program stored thereon. When the computer program is executed by a processor, the above-mentioned Figure 1 and Figure 2 The method shown.

[0127] Based on this understanding, the technical solution of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, USB flash drive, mobile hard disk, etc.), and includes a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of the present application.

[0128] Based on the above Figure 1 and Figure 2 The method shown, and Figure 4In order to achieve the above-mentioned purpose, the embodiment of the present application further provides an electronic device, such as a personal computer or a server, which includes a storage medium and a processor; the storage medium is used to store a computer program; the processor is used to execute the computer program to achieve the above-mentioned Figure 1 and Figure 2 The method shown.

[0129] In some embodiments, the physical device may further include a user interface, a network interface, a camera, a radio frequency (RF) circuit, a sensor, an audio circuit, a Wi-Fi module, and the like. The user interface may include a display, an input unit such as a keyboard, and the like. Optional user interfaces may also include a USB interface and a card reader interface. In some embodiments, the network interface may include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0130] Those skilled in the art will understand that the above-mentioned physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or a combination of certain components, or different component arrangements.

[0131] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the physical device, supporting the execution of information processing programs and other software and / or programs. The network communication module is used to enable communication between components within the storage medium, as well as with other hardware and software within the physical information processing device.

[0132] Through the above description of the embodiments, those skilled in the art will clearly understand that the present application can be implemented using software plus the necessary general hardware platform, or it can be implemented using hardware. By applying the solution of this embodiment, compared with the current existing technology, this embodiment configures preset configuration interfaces for different types of configuration items. These interfaces serve as dedicated interfaces for each configuration item, facilitating the calling of each functional module, enabling developers to clearly understand and operate the data in the EEPROM, improving the system's usability and interactivity. Furthermore, the addition of a caching mechanism and a verification mechanism reduces repeated accesses to the EEPROM, significantly shortens data read time, significantly improves system data processing efficiency, and can promptly detect data errors, ensuring that configuration data is consistent with cached data, effectively protecting data integrity, and thus improving the overall reliability of the system.

[0133] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device that includes a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device that includes the element.

[0134] The above are merely specific embodiments of the present application, which are intended to enable those skilled in the art to understand or implement the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to these embodiments herein, but rather is intended to conform to the widest scope consistent with the principles and novel features of the present application.

Claims

1. A request processing method, characterized in that: include: Obtain a configuration file corresponding to the target device, wherein the configuration file includes configuration data corresponding to different functional modules; receiving a data processing request sent by the functional module through a request processing interface, wherein the request processing interface is used to queue the data processing request; Determining target data corresponding to the data processing request from the configuration data using the request processing interface, wherein the target data is used to perform function configuration of the function module; The step of obtaining a configuration file corresponding to the target device includes: Determining a configuration file corresponding to the target device according to the device information of the target device; Obtaining configuration items corresponding to the functional modules, and performing interval detection on storage intervals of the configuration items in the configuration file; The configuration file is loaded according to the interval detection result of the storage interval.

2. The method according to claim 1, characterized in that The performing interval detection on the storage interval of the configuration item in the configuration file includes: Based on the start offset and end offset corresponding to different configuration items, detect whether the storage intervals of different configuration items overlap; The step of loading the configuration file according to the interval detection result of the storage interval includes: If it is detected that the storage intervals of the different configuration items overlap, stopping the use of the request processing interface; If it is detected that the storage intervals of the different configuration items do not overlap, the configuration file is loaded.

3. The method according to claim 2, characterized in that The detecting whether storage intervals of different configuration items overlap based on the start offsets and end offsets corresponding to different configuration items includes: Acquire a target configuration item to be detected from the configuration items, and other configuration items from the configuration items except the target configuration item; Compare the starting offset of the target configuration item with the ending offset of the other configuration items; According to the comparison result, it is determined whether the storage interval of the target configuration item overlaps with the storage interval of the other configuration items.

4. The method according to claim 1, wherein The determining, from the configuration data, target data corresponding to the data processing request using the request processing interface includes: Obtaining the configuration item corresponding to the data processing request; Determining a preset configuration interface corresponding to the configuration item from the request processing interface; The preset configuration interface is used to determine target data corresponding to the configuration item from the configuration file.

5. The method according to claim 4, characterized in that The determining, from the configuration file, target data corresponding to the configuration item using the preset configuration interface includes: Obtaining path information corresponding to the configuration item according to the attribute information corresponding to the configuration item and the description field in the configuration file; The preset configuration interface is utilized to determine the target data corresponding to the configuration item based on the path information.

6. The method according to claim 5, characterized in that The method further comprises: According to the field type corresponding to the configuration item, the target data corresponding to the configuration item is processed based on the path information.

7. The method according to claim 6, characterized in that Before processing the target data corresponding to the configuration item based on the path information according to the field type corresponding to the configuration item, the method further includes: Obtaining the preset processing rules corresponding to the field type; The processing of the target data corresponding to the configuration item based on the path information according to the field type corresponding to the configuration item includes: According to the data processing request, processing the target data corresponding to the configuration item based on the path information to obtain the processed target data; If the processed target data does not satisfy the preset processing rules corresponding to the field type, a parameter error alarm is generated.

8. The method according to claim 7, characterized in that The method further comprises: If the path information does not exist, the target data corresponding to the configuration item is processed according to the bus number and the slave device address.

9. The method according to claim 7, characterized in that After obtaining the processed target data, the method further includes: The processed target data is stored in a cache.

10. The method according to claim 8, characterized in that The method further comprises: In response to powering on the device, generating a checksum corresponding to the configuration item; The configuration data in the configuration file is verified using the verification value.

11. The method according to claim 1, wherein The receiving, through the request processing interface, the data processing request sent by the functional module comprises: The data processing requests sent by the processes corresponding to the different functional modules are received through the request processing interfaces corresponding to the different functional modules.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 11 is implemented.

13. An electronic device comprising a storage medium, a processor, and a computer program stored in the storage medium and executable on the processor, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 11 is implemented.

14. A computer program product having a computer program stored thereon, characterized in that: When the computer program product is executed by a processor, the method according to any one of claims 1 to 11 is implemented.

Images