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

Abstract

The invention discloses a request processing method, a storage medium, an electronic device and a program product, and relates to the technical field of computers.The method comprises the steps that firstly, a configuration file corresponding to a target device is obtained, and the configuration file comprises configuration data corresponding to different function modules; receiving a data processing request sent by the functional module through a request processing interface, wherein the request processing interface is used for queuing the data processing request; and finally, target data corresponding to the data processing request is determined from the configuration data by using the request processing interface, and the target data is used for performing function configuration of the function module. Compared with the prior art, the request processing interface can be used for queuing the received data processing requests sent by the function module, and then the target data of the data processing requests are determined from the configuration data, so that the multiple data processing requests can be processed in sequence, and the condition of bus competition is avoided.

Description

Technical Field

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

[0002] In the system architecture of a Baseboard Management Controller (BMC), the access of each functional module to the memory shows obvious discretization characteristics.

[0003] Currently, in the related art, the memory can be connected to the BMC via an Inter-Integrated Circuit (I2C) bus. When multiple functional modules simultaneously attempt to access the data in the memory, bus contention is likely to occur. Summary of the Invention

[0004] The present disclosure provides a request processing method, a storage medium, an electronic device, and a program product. Its main purpose is to solve the problem that in the related art, the memory can be connected to the BMC via an Inter-Integrated Circuit bus, and when multiple functional modules simultaneously attempt to access the data in the memory, bus contention is likely to occur.

[0005] In a first aspect, the present application provides a request processing method, including: Obtaining a configuration file corresponding to a target device, where the configuration file includes configuration data corresponding to different functional modules; Receiving, through a request processing interface, a data processing request sent by a functional module, where the request processing interface is used to queue the data processing request; Using the request processing interface to determine, from the configuration data, target data corresponding to the data processing request, where the target data is used for function configuration of the functional module.

[0006] In a second aspect, the present application provides a request processing apparatus, including: An obtaining module, configured to obtain a configuration file corresponding to a target device, where the configuration file includes configuration data corresponding to different functional modules; A receiving module, configured to receive, through a request processing interface, a data processing request sent by a functional module, where the request processing interface is used to queue the data processing request; A determining module, configured to use the request processing interface to determine, from the configuration data, target data corresponding to the data processing request, where the target data is used for function configuration of the functional module.

[0007] In a third aspect, the present application provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the method of the first aspect is implemented.

[0008] In a fourth aspect, the present application provides an electronic device, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor. When the processor executes the computer program, the method of the first aspect is implemented.

[0009] In a fifth aspect, the present application provides a computer program product, on which a computer program is stored. When the computer program is executed by a processor, the method of the first aspect is implemented.

[0010] The request processing method, storage medium, electronic device, and program product provided by the present disclosure, 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 the data processing request; and finally, using the request processing interface to determine target data corresponding to the data processing request from the configuration data, the target data being used for functional configuration of the functional module. Compared with the current existing technologies, the present application can first determine a configuration file matching the target device, store configuration data required by different functional modules through the configuration file, then use the request processing interface to queue the data processing requests sent by the received functional modules, and then determine the target data of the data processing requests from the configuration data, so that multiple data processing requests can be processed sequentially, avoiding the situation of bus competition, and thus ensuring the processing efficiency of the data processing requests.

[0011] It should be understood that the content described in this part is not intended to identify the key or important features of the embodiments of the present application, nor is it used 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

[0012] In order to more clearly illustrate the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0013] Figure 1 It shows a schematic flowchart of a request processing method provided by an embodiment of the present application; Figure 2 It shows a schematic flowchart of another request processing method provided by an embodiment of the present application; Figure 3 It shows a schematic diagram of an example provided by an embodiment of the present application; Figure 4 It shows a schematic structural diagram of a request processing device provided by an embodiment of the present application. Detailed implementation manners

[0014] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present application without creative efforts shall fall within the protection scope of the present application.

[0015] It should be noted that in the description of the present application, the terms "include", "comprise" or any other variant thereof are intended to cover a non-exclusive inclusion, such that a process, method, article or device including a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or device. The terms "first", "second", etc. in the present application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0016] In the BMC board of the server, a serial electrically erasable programmable read-only memory (EEPROM) chip is a common configuration. As a non-volatile memory, the EEPROM can be connected to the BMC main control chip via the I2C bus and undertakes the important task of persistently storing the key feature information of the device. It can be used to store information such as the MAC address of the BMC, the universally unique identifier (UUID) of the entire server, and the heat dissipation strategy of the entire machine. These data can all be organized in the original binary format.

[0017] In the related art, in the BMC system architecture, the access of each functional module to the EEPROM shows obvious discretization characteristics. Each functional module directly accesses the EEPROM through the I2C driver and operates on the original binary data on the EEPROM. Exemplarily, taking the heat dissipation management module and the asset management module as examples, the heat dissipation management module directly accesses the EEPROM to maintain the heat dissipation strategy, and the asset management module directly operates on the EEPROM to manage the UUID.

[0018] This decentralized access mechanism has caused a series of problems: (1) Code redundancy and maintenance challenges: Each functional module needs to handle the calculation of storage offsets and byte - order conversion on its own. This results in a large amount of duplicate content in the code, increasing not only the code volume but also making subsequent maintenance extremely difficult. Once related functions need to be modified, adjustments have to be made in multiple modules, making it very easy to overlook something.

[0019] Specifically, EEPROM usually provides two operation interfaces. One is to send read - write commands through the ioctl function, and the other is to export EEPROM as a file to sysfs for reading and writing operations as if it were an ordinary file. During the independent operation of each module on EEPROM, it is necessary to judge and select which interface to use at multiple positions, which undoubtedly increases the complexity of the code.

[0020] At the same time, each module independently maintains the offset and size information of the configuration items in EEPROM, which makes the management of the storage area chaotic. For example, the configuration items of module A and module B may overlap in the storage area, and this overlap will cause unexpected changes in data, affecting the normal operation of the system.

[0021] In addition, there are differences in the offsets and sizes of the configuration items in EEPROM for different models. In different modules, in order to adapt to different models, it is necessary to introduce model - judgment logic and select the corresponding offsets, sizes, and data - parsing methods accordingly. These additional judgment and processing logics greatly increase the code volume and significantly improve the difficulty of code maintenance. (2) Bus - competition risk: When multiple modules simultaneously attempt to access EEPROM, it is very easy to trigger bus competition. For example, during parallel erase or write operations, it may cause a hardware - bus deadlock, leading to system failures. This occurs because EEPROM only allows one module to operate at a time. If the operation of a certain module on EEPROM has not been completed and other modules initiate operation requests at this time, it will cause the operation to fail. To solve this problem, each module has to implement its own retry mechanism. However, this approach has obvious drawbacks. Modules with high - frequency access may occupy the storage device for a long time, causing the operation requests of other modules to wait for a long time, seriously affecting the overall operation efficiency of the system.

[0022] (3)Security protection risks: Each module is responsible for setting the configuration items in the EEPROM separately. The security protection measures adopted lack consistency, and it is difficult to unify the security protection measures adopted by each module. After some modules read the data, they only check whether the data is within a reasonable range, but ignore whether the data has undergone bit inversion; while other modules only focus on whether the data has undergone bit flipping, but do not consider the rationality of the data; and even some modules do not perform data verification at all. This fragmentation of security protection measures poses a great risk to the data security of the system and cannot effectively guarantee the integrity and accuracy of the data.

[0023] In order to improve the technical problem in the related art that when a memory can be connected to a BMC via a synchronous serial communication protocol bus, bus contention is easily caused when multiple functional modules simultaneously attempt to access the data in the memory.

[0024] This embodiment provides a request processing method, as Figure 1 shown, the method includes the following steps: Step 101: Obtain the configuration file corresponding to the target device, and the configuration file includes the configuration data corresponding to different functional modules.

[0025] In some embodiments, the execution subject of this embodiment can be a server, etc., on which a BMC, various functional modules, etc. are configured. Specifically, for servers of different models, there are differences in the EEPROM configuration. The target device can be a selected device to be functionally configured. To implement the selection of a suitable configuration file according to different models, the configuration data can include but is not limited to the MAC address, the UUID of the entire server, etc. Exemplarily, the configuration data required by multiple different functional modules can be written into the same configuration file, without separately saving the configuration data corresponding to each module through multiple configuration files, reducing the code amount and the difficulty of system maintenance.

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

[0027] In some embodiments, the data processing requests may include, but are not limited to, configuration requests, data read / write requests, etc. sent by each functional module. Specifically, each functional module may send data processing requests to the request processing interface of the BMC through its respective process to obtain the required configuration data. The request processing interface can be used to queue and process multiple received data processing requests. For example, the DBUS interface can be used for inter-process communication. Other processes can implement read / write operations on the EEPROM configuration items by calling these interfaces. DBUS is designed based on the bus model and realizes inter-process cooperation through concepts such as objects, interfaces, and properties. Exemplarily, if the current request processing interface is processing a data processing request sent by a certain functional module and simultaneously receives other data processing requests sent by other functional modules, the other data processing requests can be queued according to the request time and processed sequentially. By queuing each request, the situation where multiple processes simultaneously compete for the bus is effectively avoided, thereby avoiding hardware bus deadlocks and improving system stability.

[0028] Correspondingly, the request processing interface may include different interfaces provided for different functional modules, such as the RAV interface, the Pretty interface, etc. Exemplarily, the RAV interface can be used to receive requests sent by the Intelligent Platform Management Interface (IPMI), and the Pretty interface can be used to receive requests sent by the functional module and Bmcweb respectively.

[0029] Step 103: Use the request processing interface to determine the target data corresponding to the data processing request from the configuration data.

[0030] In some embodiments, a preset processing program can be configured in the BMC. The preset processing program provides a request processing interface externally and is responsible for uniformly processing the configuration items in the EEPROM, enabling the request processing interface to determine the currently processed data processing request according to the request time of each data processing request and the idle state of the interface itself, realizing inter-process communication, and then using the target data corresponding to the data processing request determined from the configuration data. The target data can be the configuration data that each functional module needs to perform read / write operations on and can be used for function configuration of the functional module. In this way, the data processing requests sent by different functional modules can be processed sequentially, enabling different functional modules to access the configuration data in the EEPROM sequentially, determining the target data required by each functional module for function configuration. Each functional module does not need to access the EEPROM distributively, reducing the code volume of the functional module distributed architecture, reducing the system maintenance difficulty, and effectively improving system stability.

[0031] Compared with the current existing technologies, in this embodiment, a configuration file corresponding to a target device is first obtained, and the configuration file includes configuration data corresponding to different functional modules; then a data processing request sent by a functional module is received through a request processing interface, and the request processing interface is used to queue the data processing request; finally, the target data corresponding to the data processing request is determined from the configuration data by using the request processing interface, and the target data is used for function configuration of the functional module. Compared with the current existing technologies, in this application, a configuration file matching the target device can be first determined, the configuration data required by different functional modules is stored through the configuration file, then the data processing requests sent by the received functional modules are queued by using the request processing interface, and then the target data of the data processing requests is determined from the configuration data, so that multiple data processing requests can be processed sequentially, avoiding the situation of bus competition, and thus ensuring the processing efficiency of the data processing requests.

[0032] To further illustrate the specific implementation process of the method in this embodiment, this embodiment provides a specific method as shown in Figure 2 and the method includes: Step 201: Determine a configuration file corresponding to the target device according to the device information of the target device.

[0033] In some embodiments, the device information may include but is not limited to device models, etc. For servers of different models, there are differences in their EEPROM configurations. The initialization system systemd of the Linux system can be used to select a suitable configuration file according to different models to adapt to the function configuration of different models. Systemd has the function of managing the startup of processes (such as heat dissipation processes, IPMI processes, WeB processes, etc.), and the startup method of the process can be defined through the systemd service unit configuration file (such as the service file).

[0034] 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 behavior, settings related to installation and service enabling, etc. Specifically, in the service file, ExecStartPre can be defined. ExecStartPre can be used to point to the script EEPROM-config-select.sh. The function of this script is to obtain the model information through the FRU (Field Replaceable Unit), and then find the EEPROM configuration file that matches the model, and soft link it to the preset storage location, such as: / etc / default / EEPROM.json. ExecStart can also be defined. ExecStart can be used to point to the EEPROM-manager, and preset parameters (such as -c) can be used to specify the configuration file to be loaded, and this configuration file points to / etc / default / EEPROM.json. The specific execution steps are as follows: (1) Start the service: systemd starts the EEPROM-manager.service; (2) Execute the script: The EEPROM-config-select.sh script is executed; (3) Obtain the model and find the configuration file: The script obtains the model name through the ipmitool fru command, and then finds the configuration file with the same name as the model name in the / usr / share / EEPROM-manager folder; (4) Process the search result: 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 the log and prompt "Configuration file for the corresponding model not found", and 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; (5) Start the management program: After the EEPROM-config-select.sh script finishes executing, it exits, and then calls EEPROM-manager -c / etc / default / EEPROM.json, and the -c parameter specifies that the configuration file to be loaded is / etc / default / EEPROM.json.

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

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

[0037] In some embodiments, the automatic identification function of the model and the configuration file can be implemented inside the EEPROM management module. By parsing the configuration file, the management module can accurately determine the EEPROM configuration information corresponding to the current model.

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

[0039] 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 according to the start offset and end offset corresponding to different configuration items.

[0040] Exemplarily, when loading the configuration file, the system will automatically detect the storage intervals of each configuration item in the EEPROM and perform configuration interval overlapping verification on all configuration items. The start offset (start position) of each configuration item can be the offset of the configuration item in the EEPROM, and the end offset (end position) can be determined according to the start offset and the occupied space size of the configuration item.

[0041] Optionally, detecting whether the storage intervals of different configuration items overlap according to the start offset and end offset corresponding to different configuration items may specifically include: obtaining the target configuration item to be detected from the configuration item, as well as other configuration items in the configuration item except the target configuration item; comparing the start offset of the target configuration item with the end offset of the other configuration items; and determining whether the storage interval of the target configuration item overlaps with the storage intervals of the other configuration items according to the comparison result.

[0042] In some embodiments, when the configuration file contains multiple configuration items, the system performs overlapping verification on each field. The specific verification method is as follows: For each configuration item, the system generates a key-value pair containing the start position (start) and the end position (end), where the value of start is the offset of the configuration item in the EEPROM, and the value of end is the offset plus the size of the space occupied by the configuration item (offset + size). After generating the key-value pair, the system sorts them in ascending order according to the start value. After the sorting is completed, the system checks each configuration item in turn. Once it is found that the start field value of a certain configuration item is less than the end field value of a previous configuration item, it is determined that there is an overlapping situation between the configuration items. If an overlap is detected, the EEPROM-manager program will immediately exit abnormally and stop providing the dbus interface externally, so as to prevent data chaos and system failures caused by overlapping configuration items, and ensure the stability of the system operation and the accuracy of the data.

[0043] For each configuration item, generate a key-value pair containing the start offset and the end offset, sort the start offset values in ascending order, and then check them in turn. Once it is found that the start offset of a certain configuration item is less than the end offset of the previous configuration item, it is determined that there is an interval overlap.

[0044] Step 203: According to the interval detection result of the storage interval, load the configuration file, where the configuration file includes configuration data corresponding to different functional modules.

[0045] Optionally, when loading the configuration file, the system will perform a series of rigorous check operations, such as: detecting whether the configuration file is an empty file, the number of configuration items in the configuration file, etc. If the configuration file is empty, the system will directly determine it as an invalid configuration. At this time, the EEPROM-manager program will exit abnormally to avoid system errors caused by invalid configurations; at least one configuration item can be stored in the same configuration file. If there is only one configuration item in the configuration file, since there is no possibility of overlap between configuration items, the system will skip the subsequent complex verification steps, thereby improving the program operation efficiency.

[0046] Exemplarily, as Figure 3 shown, the configuration file selection can be performed first to determine the configuration file corresponding to the target device, then the configuration file can be loaded, and then the configuration verification can be performed. Multiple UUIDHandlers can be used for verification.

[0047] Specifically, the EEPROM - manager program can be used to be responsible for loading the configuration file, and obtain the offset, size, field processing method (handler), and the purpose (name) represented by the field of each storage field in the EEPROM from the configuration file. The layout field of the configuration file lists the name, offset, size, option, handler, raw, and pretty of each field in the form of an array. The EEPROM_path can also be included in the configuration file.

[0048] In some embodiments, according to the interval detection result of the storage interval, loading the configuration file may specifically include: if it is detected that the storage intervals of different configuration items overlap, stop using the request processing interface; if it is detected that the storage intervals of different configuration items do not overlap, load the configuration file.

[0049] Exemplarily, if it is detected that there are configuration items with overlapping intervals, the EEPROM - manager process exits abnormally and no longer provides the DBUS interface, preventing data chaos and system exceptions caused by overlapping configuration intervals and ensuring the stable operation of the system; if it is detected that the storage intervals of different configuration items do not overlap, the configuration file can be loaded for subsequent processing.

[0050] Step 204, receive a data processing request sent by the functional module through the request processing interface.

[0051] In some embodiments, an independent EEPROM management functional module can be developed. This module has the ability to uniformly schedule and manage EEPROM access and provides a DBUS interface externally, so that other functional modules no longer directly access the EEPROM through the I2C bus, but interact with this management module through the DBUS interface. The management module will queue and process all EEPROM access requests from other functional modules and execute them in sequence, thus avoiding the competition phenomenon caused by multiple modules accessing the EEPROM simultaneously and ensuring the stable operation of the system.

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

[0053] Optionally, receive a data processing request sent by a functional module through a request processing interface, which may specifically include: receiving data processing requests sent by processes corresponding to different functional modules through request processing interfaces corresponding to different functional modules.

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

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

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

[0057] Exemplarily, preset configuration interfaces may be configured for different types of configuration items (MAC address, UUID, enumeration item, numerical attribute configuration item, etc.) respectively as the exclusive interfaces for each configuration item, which is convenient for each functional module to call, enabling developers to clearly understand and operate the data in the EEPROM. Designing such a customized and highly readable DBUS interface improves the usability and interactivity of the system.

[0058] Optionally, using the preset configuration interface to determine the target data corresponding to the configuration item from the configuration file may specifically include: obtaining the 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; using the preset configuration interface to determine the target data corresponding to the configuration item based on the path information.

[0059] Exemplarily, the specific contents of the preset configuration interfaces corresponding to different types of configuration items are as follows: The DBUS interface corresponding to the MAC address may be com.otrd.Network.MAC, and the attribute name is MACAddress. The object path is generated according to the name field describing the network card in the configuration file. After the functional module generates the path according to the network port name, it reads and writes the MACAddress attribute in combination with this interface; The interface corresponding to the UUID can be designed as com.otrd.Common.UUID, and the property name is UUID. Generate the object path according to the name field describing the UUID usage in the configuration file, and operate on the UUID property according to this path and interface during reading and writing; For enumeration items, two DBUS interfaces can be set for each enumeration item. The Pretty property of the com.otrd.EEPROM.Setting.Pretty interface is of string type and is used to describe the meaning of the enumeration item; the RawData property of the com.otrd.EEPROM.Setting.RawData interface is of byte type and represents the specific value in the EEPROM. The object paths of the two interfaces are the same and are both generated from the name field of the enumeration item usage in the configuration file. When reading and writing enumeration items (such as selecting the cooling strategy) on the BMC management web page, use the com.otrd.EEPROM.Setting.Pretty interface to operate on the Pretty property; when reading and writing through IPMI, use the com.otrd.Setting.Rawdata interface to operate on the RawData property; The DBUS interface corresponding to the numerical property configuration item can be com.otrd.Counter, and the property name is Counter. Generate the object path according to the name field describing the usage in the configuration file. The functional module first determines the path and then combines the interface to read and write the Counter property.

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

[0061] Among them, the path information may include the EEPROM path, and the EEPROM path can be obtained according to the EEPROM_path field.

[0062] 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 specifically include: obtaining the preset processing rule corresponding to the field type.

[0063] Optionally, processing the target data corresponding to the configuration item based on the path information according to the field type corresponding to the configuration item may specifically include: processing the target data corresponding to the configuration item based on the path information according to the data processing request to obtain the processed target data; if the processed target data does not meet the preset processing rule corresponding to the field type, generate a parameter error warning.

[0064] Exemplarily, the field handler can include multiple types, such as MacHandler, UUIDHandler, EnumHandler, and CountHandler. The handling rules for each type are as follows: (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 as a non-unicast MAC address, and a parameter error will be returned during setting; in other cases, the MAC address can be normally written to the EEPROM.

[0065] (2) UUIDHandler: If the UUID to be set is a byte with all 16 values being 0x00, or a byte with all 16 values being 0xff, it is determined as an illegal UUID, and a parameter error will be returned during setting; in other cases, the UUID can be normally written to the EEPROM to identify and intercept illegal UUIDs.

[0066] (3) EnumHandler: Adds an option field to associate the original binary data with its meaning. Among them, the raw field represents the value of the data in the EEPROM, and the pretty field describes its meaning in a readable string form, and the two correspond one by one.

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

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

[0069] Optionally, the method of this embodiment may specifically further include: 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.

[0070] In some embodiments, when accessing the EEPROM, the system obtains the EEPROM path based on the EEPROM_path field. If the path exists, the system accesses the EEPROM in the form of a regular file; if the path does not exist, it is necessary to parse and obtain the I2C bus number and the slave address where it is located, and then perform read and write operations on the EEPROM through the ioctl method. The parsing method is as follows: extract the string between the second-to-last and the last " / " symbols in the path. The number before the "-" symbol in this string represents the bus number, and the number after the "-" symbol is the slave address of the device (which needs to be converted to hexadecimal). For example, "1-0050" indicates that this EEPROM device is located on I2C bus 1 and the slave address is 0x50.

[0071] Correspondingly, during the process of parsing the path to obtain the I2C bus number and the slave address, if the extracted string does not conform to the format of "number - number", or an error occurs when converting the number after the "-" symbol to hexadecimal, the program will record a detailed error log, indicating that "the EEPROM path parsing failed". At this time, the system will determine subsequent operations according to the pre-set rules, either try to re-parse the path, or directly terminate the relevant operation and notify the user to ensure the reliability of the system operation.

[0072] In addition, whether accessing the EEPROM in the form of a regular file or through the ioctl method, once a read / write error occurs (such as insufficient permissions, device failure, etc.), the program will promptly capture the error. In addition to recording the error code and error description in detail in the log, it will also return an error identifier to the upper-layer application. After receiving the error identifier, the upper-layer application can take corresponding handling measures, such as prompting the user to check whether the device connection is normal and whether the permission settings are correct, etc., so as to improve the stability of the system and the user experience.

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

[0074] Specifically, in terms of data reading, to improve efficiency, after successfully reading all configuration items of the EEPROM, the EEPROM-manager can store these data in the cache. Thereafter, when the system needs to read the data again, it can directly obtain it from the cache without repeatedly accessing the EEPROM, which greatly shortens the data reading time and improves the system response speed.

[0075] Correspondingly, when the configuration in the EEPROM needs to be modified, the system will operate according to a rigorous process. First, update the corresponding configuration fields in the cache. Then, based on the updated configuration data, recalculate the check value using the CRC8 algorithm to generate a new check field. Finally, the system writes all the updated configuration items and the new check field into the EEPROM together, thereby ensuring that the data in the EEPROM is always consistent with the data in the cache, effectively guaranteeing the integrity of the data and maintaining the stable operation of the system.

[0076] In this way, a cache mechanism is introduced to optimize the EEPROM data read and write process. After successfully reading all configuration items, the data is temporarily stored in the cache, and subsequent read operations preferentially obtain data from the cache, reducing the direct access times to the EEPROM and improving the data read efficiency.

[0077] Optionally, the method of this embodiment may specifically further include: generating a check value corresponding to the configuration item in response to device power-on; using the check value to perform data verification on the configuration data in the configuration file.

[0078] In some embodiments, a unified security protection mechanism can be implemented within the EEPROM management module. This mechanism will simultaneously verify the rationality of the configuration item data and whether bit inversion has occurred. When reading and writing data, the management module will strictly check the data according to a unified verification rule to ensure the integrity and accuracy of the data. Once data anomalies are found, the management module will promptly take corresponding measures, such as rejecting the write or prompting an error message, thereby effectively enhancing the security of the system.

[0079] Specifically, to ensure the accuracy and integrity of the EEPROM data, a check field is added at the end of the EEPROM layout. This check field is generated by the CRC8 check algorithm with a polynomial of 0x07. Each time the device is powered on, the system will automatically read all configuration items from the EEPROM and recalculate the check value using the CRC8 algorithm. Subsequently, the newly calculated check value is compared with the check field originally stored in the EEPROM. Once the two are inconsistent, the system determines that the verification fails. At this time, to prevent system anomalies caused by data errors, the EEPROM-manager process will immediately terminate and stop providing the DBUS interface service.

[0080] In this way, by using a unified CRC check mechanism and adopting the CRC8 check algorithm with a polynomial of 0x07, the entire storage space of the EEPROM is checked. Whether when the device is powered on or after the data is modified, the check value is recalculated and compared with the check field stored in the EEPROM to promptly detect and avoid error situations such as data bit inversion, ensuring the integrity and accuracy of the data.

[0081] As a possible implementation, as Figure 3 shown, a system architecture diagram is presented. The EEPROM - manager can be used to manage the configuration and operation of the EEPROM. The RAW interface can be used to interface with 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, and then can identify the data and structure in the EEPROM, and communicate with the EEPROM through I2c ioctl or an EEPROM file (EEPROM file) to perform read and write operations on configuration data. Among them, I2C ioctl can perform input / output control through the I2C bus and is used to communicate with the EEPROM.

[0082] In this way, an independent EEPROM management module is constructed and inter - process communication is carried out through the DBUS interface to achieve an orderly scheduling of EEPROM access. This method changes the previous mode of direct concurrent access by multiple modules. The access requests to the EEPROM are queued and processed in the management module, fundamentally eliminating the bus conflicts caused by multiple modules simultaneously reading and writing the EEPROM, ensuring the stable operation of the hardware bus, avoiding serious problems such as deadlocks, and providing a solid guarantee for the system to stably read and write the EEPROM.

[0083] Secondly, a unified EEPROM identification and configuration detection strategy is also proposed. In terms of identification, standardized identification rules are formulated for different types of configuration items. For example, exclusive 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. The configuration detection strategy covers functions such as configuration - file identification, storage - area overlap verification, and unified selection of operation interfaces. The implementation of these strategies avoids operations such as repeated offset calculation, byte - order conversion, and interface - selection judgment by each module, effectively reducing code redundancy. At the same time, the unified and standardized management mode reduces the risk of configuration errors, improves system reliability, and makes subsequent system maintenance and function expansion more convenient and efficient.

[0084] In addition, a cache and CRC check mechanism are introduced to improve the system performance. During the read and write operations of the EEPROM, a cache mechanism and a CRC check mechanism are added. After successfully reading all configuration items, the cache mechanism stores the data in the cache. Subsequently, the read operation directly retrieves the data from the cache, reducing the repeated access to the EEPROM, significantly shortening the data read time, and remarkably improving the system data processing efficiency. The CRC check mechanism adopts the CRC8 check algorithm with a polynomial of 0x07. It checks all the configuration items of the EEPROM when the device is powered on, and recalculates the check value and updates the EEPROM check field every time the data is modified. In this way, data errors such as bit inversion can be detected in a timely manner, ensuring the consistency between the EEPROM data and the cache data, effectively guaranteeing the data integrity, and further enhancing the overall reliability of the system.

[0085] Compared with the related technologies, in this embodiment, preset configuration interfaces are respectively configured for different types of configuration items as the exclusive interfaces for each configuration item, facilitating the call of each functional module, enabling developers to clearly understand and operate the data in the EEPROM, improving the system usability and interactivity, and adding a cache mechanism and a check mechanism, reducing the repeated access to the EEPROM, significantly shortening the data read time, remarkably improving the system data processing efficiency, and being able to detect data errors in a timely manner, ensuring the consistency between the configuration data and the cache data, effectively guaranteeing the data integrity, and further enhancing the overall reliability of the system.

[0086] An embodiment of the present application further provides a request processing device, as Figure 1 and Figure 2 shown in the specific implementation of the method, as Figure 4 shown, the device includes: an acquisition module 31, a reception module 32, and a determination module 33.

[0087] The acquisition module 31 is configured to acquire a configuration file corresponding to a target device, and the configuration file includes configuration data corresponding to different functional modules; The reception module 32 is configured to receive a data processing request sent by a functional module through a request processing interface, and the request processing interface is used to queue the data processing request; The determination module 33 is configured to use the request processing interface to determine target data corresponding to the data processing request from the configuration data, and the target data is used for the function configuration of the functional module.

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

[0089] In some examples of this embodiment, the obtaining module 31 is specifically configured to detect whether the storage ranges of different configuration items overlap according to the start offset and end offset corresponding to different configuration items; and load the configuration file according to the range detection result of the storage range, including: if it is detected that the storage ranges of different configuration items overlap, stop using the request processing interface; if it is detected that the storage ranges of different configuration items do not overlap, load the configuration file.

[0090] In some examples of this embodiment, the determining module 33 is specifically configured to obtain a target configuration item to be detected from the configuration items, and other configuration items except the target configuration item in the configuration items; compare the start offset of the target configuration item with the end offset of the other configuration items; and determine whether the storage range of the target configuration item overlaps with the storage ranges of the other configuration items according to the comparison result.

[0091] In some examples of this embodiment, the determining 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.

[0092] In some examples of this embodiment, the determining module 33 is specifically configured to obtain the 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; and use the preset configuration interface to determine the target data corresponding to the configuration item based on the path information.

[0093] In some examples of this embodiment, the determining module 33 is further specifically 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.

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

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

[0096] In some examples of this embodiment, the determining module 33 is further specifically configured to store the processed target data in the cache.

[0097] In some examples of this embodiment, the determining module 33 is specifically further configured to generate a verification value corresponding to a configuration item in response to the device being powered on; and use the verification value to perform data verification on the configuration data in the configuration file.

[0098] 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 the different functional modules.

[0099] It should be noted that for other corresponding descriptions of each functional unit involved in the request processing device provided in this embodiment, reference can be made to Figure 1 and Figure 2 the corresponding descriptions in, which will not be elaborated here.

[0100] Based on the above methods as shown in Figure 1 and Figure 2 correspondingly, this embodiment further provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the above methods as shown in Figure 1 and Figure 2 are implemented.

[0101] Based on the above methods as shown in Figure 1 and Figure 2 correspondingly, this embodiment further provides a computer program product, on which a computer program is stored, and when the computer program is executed by a processor, the above methods as shown in Figure 1 and Figure 2 are implemented.

[0102] Based on such an understanding, the technical solution of this 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, a USB flash drive, a mobile hard disk, etc.), and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods of various implementation scenarios of this application.

[0103] Based on the above methods as shown in Figure 1 and Figure 2 and the virtual device embodiment as shown in Figure 4 in order to achieve the above purpose, this embodiment of the application further provides an electronic device, such as a personal computer or a server, and the device includes a storage medium and a processor; the storage medium is used for storing a computer program; the processor is used for executing the computer program to implement the above methods as shown in Figure 1 and Figure 2 are implemented.

[0104] In some embodiments, the above-mentioned physical device may further include a user interface, a network interface, a camera, a radio frequency (RF) circuit, sensors, an audio circuit, a WI-FI module, and so on. The user interface may include a display screen (Display), an input unit such as a keyboard (Keyboard), etc. Optionally, the user interface may further include a USB interface, a card reader interface, etc. The network interface may include a standard wired interface, a wireless interface (such as a WI-FI interface), etc. in some embodiments.

[0105] Those skilled in the art can understand that the structure of the above-mentioned physical device provided in this embodiment does not constitute a limitation on the physical device, and it may include more or fewer components, or combine some components, or have different component arrangements.

[0106] The storage medium may further include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the above-mentioned physical device and supports the operation of information processing programs and other software and / or programs. The network communication module is used to implement communication between components inside the storage medium, as well as communication between other hardware and software in the information processing physical device.

[0107] Through the description of the above embodiments, those skilled in the art can clearly understand that the present application can be implemented by means of software plus a necessary general hardware platform, or by hardware. By applying the solution of this embodiment, compared with the current prior art, in this embodiment, preset configuration interfaces are configured for different types of configuration items as exclusive interfaces for each configuration item, which facilitates the call of each functional module, enables developers to clearly understand and operate the data in the EEPROM, improves the usability and interactivity of the system, and adds a caching mechanism and a verification mechanism, reduces the repeated access to the EEPROM, significantly shortens the data reading time, significantly improves the system data processing efficiency, and can timely detect data errors, ensure the consistency of the configuration data and the cached data, effectively guarantee the data integrity, and further improve the overall reliability of the system.

[0108] It should be noted that, in this document, relational terms such as "first" and "second" are only used 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 term "comprising", "including" or any other variant thereof is 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 expressly listed, or elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, article or device comprising the element.

[0109] The above are only specific embodiments of the present application, enabling those skilled in the art to understand or implement the present application. Various modifications to these embodiments will be obvious to those skilled in the art, and the general principles defined herein can 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 will conform to the broadest scope consistent with the principles and novel features claimed herein.

Claims

1. A request processing method, characterized in that, Including: Obtain a configuration file corresponding to the target device, where the configuration file includes configuration data corresponding to different functional modules; Receive a data processing request sent by the functional module through a request processing interface, where the request processing interface is used to queue the data processing request; Use the request processing interface to determine target data corresponding to the data processing request from the configuration data, and the target data is used for function configuration of the functional module.

2. The method according to claim 1, wherein The obtaining of the configuration file corresponding to the target device includes: Determine the configuration file corresponding to the target device according to the device information of the target device; Obtain configuration items corresponding to the functional module, and perform interval detection on the storage interval of the configuration items in the configuration file; Load the configuration file according to the interval detection result of the storage interval.

3. The method according to claim 2, wherein The performing of interval detection on the storage interval of the configuration items in the configuration file includes: Detect whether the storage intervals of different configuration items overlap according to the start offset and end offset corresponding to different configuration items; The loading of the configuration file according to the interval detection result of the storage interval includes: If it is detected that the storage intervals of different configuration items overlap, stop using the request processing interface; If it is detected that the storage intervals of different configuration items do not overlap, load the configuration file.

4. The method according to claim 3, characterized in that, The detecting of whether the storage intervals of different configuration items overlap according to the start offset and end offset corresponding to different configuration items includes: Obtain a target configuration item to be detected from the configuration items, and other configuration items in the configuration items except the target configuration item; Compare the start offset of the target configuration item with the end offset of the other configuration items; Determine whether the storage interval of the target configuration item overlaps with the storage interval of the other configuration items according to the comparison result.

5. The method according to claim 2, wherein The using of the request processing interface to determine target data corresponding to the data processing request from the configuration data includes: Obtain configuration items corresponding to the data processing request; Determine a preset configuration interface corresponding to the configuration item from the request processing interface; Use the preset configuration interface to determine target data corresponding to the configuration item from the configuration file.

6. The method according to claim 5, characterized in that The using of the preset configuration interface to determine target data corresponding to the configuration item from the configuration file includes: Obtain 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; Use the preset configuration interface to determine the target data corresponding to the configuration item based on the path information.

7. The method according to claim 6, wherein The method further includes: Process the target data corresponding to the configuration item based on the path information according to the field type corresponding to the configuration item.

8. The method according to claim 7, wherein Before 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, the method further includes: Obtain a preset processing rule 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: Based on the data processing request, process the target data corresponding to the configuration item according to the path information, and obtain the processed target data; If the processed target data does not meet the preset processing rules corresponding to the field type, generate a parameter error alarm.

9. The method according to claim 8, wherein The method further includes: If the path information does not exist, process the target data corresponding to the configuration item according to the bus number and the slave device address.

10. The method according to claim 8, characterized in that After obtaining the processed target data, the method further includes: Store the processed target data in the cache.

11. The method according to claim 9, wherein The method further includes: In response to the device power-on, generate a check value corresponding to the configuration item; Use the check value to perform data verification on the configuration data in the configuration file.

12. The method according to claim 1, wherein Receiving the data processing request sent by the functional module through the request processing interface includes: Receiving the data processing requests sent by the processes corresponding to different functional modules through the request processing interfaces corresponding to different functional modules.

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

14. An electronic device, comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein, When the processor executes the computer program, it implements the method according to any one of claims 1 to 12.

15. A computer program product having a computer program stored thereon, characterized in that, When the computer program product is executed by a processor, it implements the method according to any one of claims 1 to 12.

Images