Command processing method, device, substrate management controller, program product, and medium

Abstract

This invention provides a command processing method, apparatus, baseboard management controller, program product, and medium, relating to the field of baseboard management controllers. It applies to a first operating system within the baseboard management controller, which also includes a second operating system. The first operating system has a higher response speed than the second operating system. The method includes: when the baseboard management controller triggers a startup operation, performing a system initialization operation and establishing an inter-core communication channel with the second operating system; the startup operation triggers both the first and second operating systems to perform system initialization operations; upon determining that it has completed initialization, receiving and responding to out-of-band management commands from the server; using the inter-core communication channel to determine whether the second operating system has completed initialization; and upon determining that the second operating system has completed initialization, transferring the right to receive and respond to out-of-band management commands from the server to the second operating system; enabling rapid response to out-of-band management commands from the server.

Description

Technical Field

[0001] This invention relates to the field of board management controllers, and particularly to a command processing method, apparatus, board management controller, program product, and medium. Background Technology

[0002] The Baseboard Management Controller (BMC) is an important component of the server. It has an out-of-band management interface for the server, which can receive and respond to input out-of-band management commands to realize out-of-band management of the server.

[0003] In related technologies, the baseboard management controller cannot respond to out-of-band management commands input from the server during the startup process of its internal operating system; furthermore, the operating system in the baseboard management controller has a long startup time, thus failing to meet the user's demand for a fast response from the baseboard management controller. Summary of the Invention

[0004] The purpose of this invention is to provide a command processing method, apparatus, baseboard management controller, program product, and medium that can add a first operating system with a faster response speed to the baseboard management controller and add a mechanism for receiving and responding to out-of-band management commands from the server to the first operating system, thereby enabling a fast response to out-of-band management commands from the server during the startup process of the baseboard management controller.

[0005] To address the aforementioned technical problems, this invention provides a command processing method applied to a first operating system in a baseboard management controller. The baseboard management controller further includes a second operating system, wherein the response speed of the first operating system is higher than that of the second operating system. The method includes:

[0006] When the baseboard management controller triggers a startup operation, it performs a system initialization operation and establishes an inter-core communication channel with the second operating system; the startup operation is used to trigger both the first operating system and the second operating system to perform the system initialization operation.

[0007] Upon confirming that it has completed initialization, it receives and responds to out-of-band management commands from the server;

[0008] The inter-core communication channel is used to determine whether the second operating system has completed initialization;

[0009] When the second operating system completes initialization, the right to receive and respond to the out-of-band management commands of the server is transferred to the second operating system, so that the second operating system can receive and respond to the out-of-band management commands of the server.

[0010] Optionally, receive and respond to out-of-band management commands from the server, including:

[0011] The system receives out-of-band management commands from external devices via the network, executes the out-of-band management commands to obtain execution results, and then sends the execution results back to the external devices via the network.

[0012] Optionally, receiving out-of-band management commands from an external device via a network, executing the out-of-band management commands to obtain execution results, and sending the execution results back to the external device via the network, includes:

[0013] The first thread receives a request command through the connection socket interface with the external device and sends the request command to the second thread.

[0014] The second thread determines the type of the request command. If the request command is determined to be a session establishment command, the session establishment command is processed to obtain session establishment response information, and the session establishment response information is sent to the fourth thread. Alternatively, if the request command is determined to be a server out-of-band management command, the server out-of-band management command is sent to the third thread.

[0015] The third thread executes the out-of-band management command of the server to obtain the execution result, and then sends the execution result to the fourth thread;

[0016] The fourth thread uses the connection socket interface to send the session establishment response information or the execution result to the external device.

[0017] Optionally, the first thread receives a request command through a connection socket interface with the external device and sends the request command to the second thread, including:

[0018] The first thread is used to determine whether the connection socket interface has been triggered.

[0019] If the connection socket interface is triggered, the header of the network data packet sent by the external device is received through the connection socket interface, and it is determined whether the header has been successfully received.

[0020] If the data header is successfully received, the request command in the network data packet will continue to be received through the connection socket interface, and it will be determined whether the request command has been successfully received.

[0021] If the request command is successfully received, the request command is sent to the second thread.

[0022] Optionally, before the first thread determines whether the connection socket interface has been triggered, the method further includes:

[0023] The first thread is used to determine whether the listening socket interface used to receive out-of-band management commands from the server is active.

[0024] If the listening socket interface is already active, then determine whether the listening socket interface has been triggered by the external device.

[0025] If the listening socket interface is triggered by the external device, the listening socket interface is set to the accept state, and a connection socket interface corresponding to the external device is created.

[0026] Optionally, sending the request command to the second thread includes:

[0027] The first thread sends the request command to the second thread via a message queue.

[0028] Optionally, before receiving the request command through the connection socket interface with the external device using the first thread, the method further includes:

[0029] The value of the first thread activation flag is determined using the first thread;

[0030] If the activation flag of the first thread is a first value, then proceed to the step of receiving request commands through the connection socket interface between the first thread and the external device.

[0031] If the activation flag of the first thread is the second value, then the first thread is destroyed;

[0032] Before using the fourth thread to send the session establishment response information or the execution result to the external device through the connection socket interface, the method further includes:

[0033] The value of the activation flag of the second thread is determined using the fourth thread;

[0034] If the activation flag of the second thread is the first value, then proceed to the step of using the fourth thread to send the session establishment response information or the execution result to the external device through the connection socket interface;

[0035] If the activation flag of the second thread is a second value, then the fourth thread is destroyed. Optionally, the right to receive a response includes network control rights and interface control rights for the server's out-of-band management commands;

[0036] Transferring the right to receive and respond to out-of-band management commands from the server to the second operating system includes:

[0037] The network control and the interface control are sequentially transferred to the second operating system. When the network control is transferred, the execution result is sent to the external device through the second operating system. When the interface control is transferred, the unprocessed out-of-band management commands of the server are sent to the second operating system.

[0038] Optionally, the network control and the interface control are sequentially transferred to the second operating system. When the network control transfer is complete, the execution result is sent to the external device through the second operating system. When the interface control transfer is complete, unexecuted out-of-band server management commands are sent to the second operating system, including:

[0039] Stop receiving the server out-of-band management commands, cache unprocessed server out-of-band management commands, and continue to execute unprocessed server out-of-band management commands;

[0040] The network control is transferred to the second operating system;

[0041] When the network control is transferred, the execution result is sent to the second operating system through the inter-core communication channel, so that the second operating system can send the execution result to the external device through the network;

[0042] The interface control is transferred to the second operating system;

[0043] When the interface control is transferred, any unprocessed out-of-band server management commands are sent to the second operating system through the inter-core communication channel.

[0044] Optionally, receive and respond to out-of-band management commands from the server, including:

[0045] The system receives out-of-band server management commands from the local user via a serial communication interface, executes the out-of-band server management commands to obtain execution results, and outputs the execution results via the serial communication interface.

[0046] Optionally, after transferring the right to receive and respond to the out-of-band management commands of the server to the second operating system, the method further includes:

[0047] The inter-core communication channel is used to detect whether the second operating system is encountering an anomaly.

[0048] When it is determined that the second operating system has encountered an anomaly, the right to receive and respond to out-of-band management commands from the server is taken over.

[0049] The present invention also provides a command processing method applied to a second operating system in a baseboard management controller, wherein the baseboard management controller further includes a first operating system, the first operating system having a higher response speed than the second operating system, the method comprising:

[0050] When the baseboard management controller triggers the startup operation, it performs a system initialization operation and establishes an inter-core communication channel with the first operating system. The startup operation is used to trigger both the first operating system and the second operating system to perform the system initialization operation. When the first operating system determines that it has completed initialization, it receives and responds to the out-of-band management command from the server and determines whether the second operating system has completed initialization through the inter-core communication channel.

[0051] Upon confirming that it has completed initialization, it has the right to receive out-of-band management commands from the first operating system.

[0052] Upon completion of the reception of the response right, the server out-of-band management command is received and responded to.

[0053] Optionally, the right to receive a response includes network control rights and interface control rights for the server's out-of-band management commands;

[0054] The right to receive responses to out-of-band management commands transferred by the first operating system includes:

[0055] The system sequentially receives network control and interface control transferred from the first operating system. When the network control is transferred, it receives the execution result of the server out-of-band management command sent by the first operating system and sends it to the corresponding external device via the network. When the interface control receives the unprocessed server out-of-band management command sent by the first operating system, it continues to execute it.

[0056] Optionally, the system sequentially receives network control and interface control transferred from the first operating system. Upon completion of the network control transfer, it receives the execution result of the out-of-band server management command sent by the first operating system and transmits it to an external device via the network. Upon receiving and continuing to execute the unprocessed out-of-band server management command sent by the first operating system, the interface control system includes:

[0057] Receive network control transferred from the first operating system;

[0058] When the network control is transferred, the execution result sent by the second operating system is received through the inter-core communication channel, and the execution result is sent to the external device through the network;

[0059] Receive interface control transferred from the first operating system;

[0060] When the interface control is handed over, the system receives the unprocessed out-of-band server management commands sent by the first operating system through the inter-core communication channel and continues to execute the unprocessed out-of-band server management commands.

[0061] The present invention also provides a command processing apparatus for use in a first operating system of a baseboard management controller, the baseboard management controller further comprising a second operating system, wherein the response speed of the first operating system is higher than that of the second operating system, the apparatus comprising:

[0062] An initialization module is used to perform system initialization operations and establish an inter-core communication channel with the second operating system when the baseboard management controller triggers a startup operation; the startup operation is used to trigger both the first operating system and the second operating system to perform the system initialization operation;

[0063] The command receiving and response module is used to receive and respond to out-of-band management commands from the server when it determines that it has completed initialization.

[0064] The judgment module is used to determine whether the second operating system has completed initialization using the inter-core communication channel;

[0065] The handover module is used to transfer the right to receive and respond to the server out-of-band management commands to the second operating system when it is determined that the second operating system has completed initialization, so that the second operating system can receive and respond to the server out-of-band management commands.

[0066] The present invention also provides a command processing apparatus for use in a second operating system of a baseboard management controller, wherein the baseboard management controller further includes a first operating system, the first operating system having a higher response speed than the second operating system, and the apparatus comprising:

[0067] An initialization module is used to perform system initialization operations and establish an inter-core communication channel with the first operating system when the baseboard management controller triggers a startup operation; the startup operation is used to trigger both the first operating system and the second operating system to perform the system initialization operation; when the first operating system determines that it has completed initialization, it receives and responds to out-of-band management commands from the server, and determines whether the second operating system has completed initialization through the inter-core communication channel;

[0068] The handover module is used to receive the right to receive out-of-band management commands from the server handed over by the first operating system when it determines that it has completed initialization.

[0069] The command receiving and response module is used to receive and respond to out-of-band management commands from the server when the receiving response right is completed.

[0070] The present invention also provides a baseboard management controller, comprising:

[0071] Memory, used to store the operating system program of the first operating system and the operating system program of the second operating system;

[0072] The processor is configured to execute the command processing method described above when loading the operating system program of the first operating system, or when loading the operating system program of the second operating system.

[0073] Optionally, the processor includes a main processor and a coprocessor, wherein the main processor runs the second operating system and the coprocessor runs the first operating system.

[0074] The present invention also provides a computer program product, including a computer program or instructions, which, when executed by a processor, implement the command processing method described above.

[0075] The present invention also provides a computer-readable storage medium storing computer-executable instructions, which, when loaded and executed by a processor, implement the command processing method described above.

[0076] This invention provides a command processing method applied to a first operating system in a baseboard management controller, wherein the baseboard management controller further includes a second operating system, the first operating system having a higher response speed than the second operating system. The method includes: when the baseboard management controller triggers a startup operation, performing a system initialization operation and establishing an inter-core communication channel with the second operating system; the startup operation is used to trigger both the first and second operating systems to perform the system initialization operation; upon determining that it has completed initialization, receiving and responding to an out-of-band management command from a server; using the inter-core communication channel to determine whether the second operating system has completed initialization; and upon determining that the second operating system has completed initialization, transferring the right to receive and respond to the out-of-band management command from the server to the second operating system, so that the second operating system receives and responds to the out-of-band management command from the server.

[0077] The beneficial effects of this invention are as follows: This invention allows for the simultaneous configuration of a first operating system and a second operating system within a baseboard management controller. The first operating system, being a newly added operating system, has a faster response speed than the second operating system, enabling it to complete system initialization in a shorter time. Furthermore, the first operating system in this invention also possesses the ability to receive and respond to out-of-band (OB) management commands from the server. After the baseboard management controller triggers a startup operation and simultaneously triggers system initialization operations for both the first and second operating systems, the first operating system can complete initialization earlier than the second operating system and prioritize receiving and responding to OB management commands from the server to meet user needs. In addition, the first operating system can establish an inter-core communication channel with the second operating system and use this channel to determine whether the second operating system has completed initialization. Upon determining that the second operating system has completed initialization, the first operating system can transfer the right to receive and respond to OB management commands from the server to the second operating system, allowing the second operating system to continue receiving and responding to OB management commands, thereby achieving a smooth transition in OB management command reception and response services. This invention also provides a command processing device, a baseboard management controller, a computer-readable storage medium, and a computer program product, which possess the aforementioned beneficial effects. Attached Figure Description

[0078] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0079] Figure 1 A flowchart of a command processing method provided in an embodiment of the present invention;

[0080] Figure 2 A flowchart of another command processing method provided in an embodiment of the present invention;

[0081] Figure 3 This is a schematic diagram of an IPMI system architecture provided in an embodiment of the present invention;

[0082] Figure 4 A flowchart of an IPMI processing flow on the real-time operating system side provided in an embodiment of the present invention;

[0083] Figure 5 A flowchart of thread interaction provided in an embodiment of the present invention;

[0084] Figure 6 A flowchart of a remote IPMI command execution process provided in an embodiment of the present invention;

[0085] Figure 7 This is a flowchart of socket creation and network data reception provided in an embodiment of the present invention;

[0086] Figure 8 A flowchart of a remote IPMI command execution and transmission process provided in an embodiment of the present invention;

[0087] Figure 9 This is a flowchart of a response handover process provided in an embodiment of the present invention;

[0088] Figure 10 This is a structural block diagram of a command processing device provided in an embodiment of the present invention;

[0089] Figure 11 This is a structural block diagram of another command processing device provided in an embodiment of the present invention;

[0090] Figure 12 This is a structural block diagram of a baseboard management controller provided in an embodiment of the present invention. Detailed Implementation

[0091] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0092] The Baseboard Management Controller (BMC) is a crucial component of the server. It features an out-of-band management interface that receives and responds to out-of-band management commands to enable out-of-band server management. A common out-of-band management interface is the Intelligent Platform Management Interface (IPMI), and the corresponding out-of-band management commands are referred to as IPMI commands.

[0093] In related technologies, the baseboard management controller cannot respond to input out-of-band management commands from the server during the startup process of its internal operating system; furthermore, the operating system in the baseboard management controller has a long startup time, thus failing to meet the user's demand for rapid response. In view of this, to address the technical problem of how to quickly respond to out-of-band management commands from the server during the startup of the baseboard management controller, this invention adds a first operating system with a shorter startup time to the baseboard management controller, and adds a mechanism for receiving and responding to out-of-band management commands from the server to this first operating system, thereby enabling rapid response to out-of-band management commands from the server during the startup process of the baseboard management controller.

[0094] To make it easier to understand, we will first give a brief introduction to the first and second operating systems.

[0095] In this embodiment, the response speed of the first operating system is higher than that of the second operating system. For example, when the first and second operating systems perform system initialization operations simultaneously, the first operating system can complete system initialization before the second operating system. This embodiment does not limit the specific form of the first operating system; it can be set according to actual application requirements, as long as it meets the requirement of having a higher response speed than the second operating system. Specifically, the first operating system can be a real-time operating system (RTOS). A real-time operating system is an operating system that can guarantee the completion of specific functions within a certain time limit, possessing characteristics such as fast response speed and high reliability. During the startup process, the real-time operating system has a defined startup time, which is usually short. Therefore, in this embodiment, a real-time operating system can be used as the first operating system, and a mechanism for receiving and responding to out-of-band server management commands can be added to the first operating system to respond to out-of-band server management commands first.

[0096] The aforementioned second operating system can be a non-real-time (RTO) operating system. A non-RTO, also known as a time-sharing operating system, refers to an operating system based on time-slice rotation. Such operating systems offer strong performance, and when placed on the baseboard management controller, they can provide rich out-of-band (OIB) server management functions. However, non-RTOs do not guarantee the completion of specific tasks within a specified time; instead, they focus on the average response time of all tasks. For example, during startup, non-RTOs typically suffer from loading a lot of content and having long initialization processes, resulting in a relatively slow startup process and an inability to guarantee startup time. Simultaneously, during this process, because the non-RTO has not completed the loading of the kernel and drivers related to the server OIB management interface, it cannot process server OIB management commands, easily leading to a poor user experience of slow baseboard management controller response and clunky operation. However, the performance of non-RTOs is generally higher than that of real-time (RTOs), thus providing richer server OIB management services compared to the latter. In other words, a real-time (RTO) operating system cannot completely replace a non-RTO in providing complex server OIB management functions.

[0097] Combining the advantages and disadvantages of the two operating systems mentioned above, this invention can simultaneously house a first operating system and a second operating system within the baseboard management controller. Furthermore, it can add a lightweight out-of-band (OBB) management command receiving and response mechanism to the first operating system, and establish a mechanism for transferring the right to receive and respond to OBB management commands between the first and second operating systems. Thus, during the baseboard management controller startup process, the first operating system can complete system initialization in advance and prioritize providing lightweight OBB management functions to the outside world. Upon completion of the second operating system startup, the first operating system can transfer the right to receive and respond to the second operating system, allowing the latter to continue providing richer OBB management functions. This satisfies users' needs for rapid response from the baseboard management controller while also ensuring the quality of subsequent OBB management.

[0098] It is understood that both operating systems require a processor in the baseboard management controller to run. It should be noted that this embodiment does not limit the processor configuration in the baseboard management controller; it can have one processor or multiple processors (e.g., two). With one processor, the first and second operating systems can run on different cores of that processor. With multiple processors, the first and second operating systems can run on different processors. For example, the baseboard management controller can have one main processor and one coprocessor; the main processor runs the second operating system, while the coprocessor runs the first operating system.

[0099] Based on the above introduction, the command processing method provided in this embodiment will be described below. For ease of understanding, please refer to... Figure 1 , Figure 1 A flowchart illustrating a command processing method provided in an embodiment of the present invention is shown. This method is applied to a first operating system in a baseboard management controller, which further includes a second operating system. The response speed of the first operating system is higher than that of the second operating system. The method may include:

[0100] S101. When the baseboard management controller triggers the startup operation, a system initialization operation is performed, and an inter-core communication channel is established with the second operating system; the startup operation is used to trigger both the first operating system and the second operating system to perform the system initialization operation.

[0101] In this step, when the baseboard management controller triggers the startup operation, it can trigger both the first operating system and the second operating system to perform system initialization operations. Additionally, during the startup process, the first operating system needs to establish an inter-core communication channel with the second operating system. This channel can be used by the first operating system to detect whether the second operating system has completed initialization and to transmit data, as described in subsequent embodiments.

[0102] It should be noted that this embodiment does not limit the form and establishment method of the inter-core communication channel. The inter-core communication channel can be implemented based on inter-process communication or shared memory, and can be set according to actual application requirements.

[0103] It should also be noted that, to achieve lightweight server out-of-band management command reception and response capabilities, the first operating system's system initialization operations should include not only system kernel initialization operations but also command reception and command response initialization operations. Command reception initialization operations could include, for example, network initialization operations or serial bus interface initialization operations.

[0104] S102. Upon confirming that it has completed initialization, receive and respond to out-of-band management commands from the server.

[0105] As mentioned above, the first operating system can complete initialization before the second operating system. Therefore, in this step, the first operating system can begin receiving and responding to out-of-band management commands from the server as soon as it determines that it has completed initialization. This can greatly reduce latency and improve system reliability and user experience during critical tasks or emergency management operations (such as restarting or shutting down).

[0106] It should be noted that this embodiment does not limit the input method of server out-of-band management commands. For example, they can be input by external devices via the network or through a local serial communication interface. Therefore, the first operating system can either receive server out-of-band management commands sent by external devices via the network and send the execution result of the command to the external device via the network; or it can receive locally input server out-of-band management commands through the serial communication interface and output the execution result of the command through the serial communication interface. In other words, the first operating system can have the control capabilities of network devices (such as network interface cards, NICs) and serial communication interfaces.

[0107] Therefore, in one scenario, receiving and responding to out-of-band management commands from the server may include:

[0108] Step 11: Receive out-of-band management commands from external devices via the network, execute the out-of-band management commands to obtain execution results, and send the execution results to the external devices via the network.

[0109] It should be noted that this embodiment does not limit the type of external device, such as a personal computer, server, mobile device, etc.

[0110] In another scenario, receiving and responding to out-of-band management commands from the server may include:

[0111] Step 21: Receive the server out-of-band management command input locally through the serial communication interface, execute the server out-of-band management command to obtain the execution result, and output the execution result through the serial communication interface.

[0112] It should be noted that this embodiment is not limited to a specific serial communication interface, such as the KCS interface (Keyboard Controller Style, KCS interface protocol).

[0113] It should also be noted that this embodiment does not limit how the first operating system receives and responds to out-of-band management commands from the server. It can be configured according to actual application requirements, for example, it can be configured with reference to the functions of the IPMI driver.

[0114] S103. Use the inter-core communication channel to determine whether the second operating system has completed initialization. If the second operating system has completed initialization, proceed to step S104; if the second operating system has not completed initialization, proceed to step S103.

[0115] As mentioned above, since the performance of the first operating system is weaker than that of the second operating system, it generally provides lightweight out-of-band server management functions and cannot completely replace the second operating system. Therefore, in this step, after the first operating system completes initialization, it also needs to determine whether the second operating system has completed initialization through the inter-core communication channel. This is so that when the latter is confirmed to have completed initialization, the right to receive and respond to out-of-band server management commands can be promptly transferred to the second operating system. It should be noted that steps S102 and S103 are executed in parallel.

[0116] It should also be noted that this embodiment does not limit how the first operating system determines whether the second operating system has completed initialization through the inter-core communication channel. For example, the first operating system can send an initialization status query request to the second operating system through the channel and determine whether the second operating system has completed initialization based on the response of the second operating system; alternatively, the second operating system can actively send initialization completion information to the first operating system when it completes initialization, so that the latter can determine that the former has completed initialization.

[0117] S104. When it is determined that the second operating system has completed initialization, the right to receive and respond to the server out-of-band management command is transferred to the second operating system, so that the second operating system can receive and respond to the server out-of-band management command.

[0118] In this step, once the second operating system has completed initialization, the first operating system can transfer the right to receive and respond to out-of-band management commands to the second operating system, so that the second operating system can continue to provide more complex out-of-band management functions. This ensures a smooth transition of out-of-band management functions and guarantees the service quality of subsequent management functions.

[0119] Based on the above embodiments, the present invention can simultaneously configure a first operating system and a second operating system in the baseboard management controller. The first operating system is a newly added operating system with a faster response speed than the second operating system, thus enabling it to complete system initialization in a shorter time. Furthermore, the first operating system in this invention also has the ability to receive and respond to out-of-band management commands from the server. After the baseboard management controller triggers a startup operation and simultaneously triggers system initialization operations for both the first and second operating systems, the first operating system can complete initialization earlier than the second operating system and prioritize receiving and responding to out-of-band management commands from the server to meet user needs. In addition, the first operating system can establish an inter-core communication channel with the second operating system and use this channel to determine whether the second operating system has completed initialization. When it is determined that the second operating system has completed initialization, the first operating system can transfer the right to receive and respond to out-of-band management commands from the server to the second operating system, allowing the second operating system to continue receiving and responding to out-of-band management commands, thereby achieving a smooth transition of out-of-band management command reception and response services.

[0120] Based on the above embodiments, the specific method by which the first operating system receives and responds to out-of-band management commands from the server via the network is described below. In one possible scenario, the first operating system includes a first thread (LANRECV), a second thread (LANHANDLER), a third thread (IPMIMSGHANDLER), and a fourth thread (LANSEND). These four threads are respectively responsible for command reception, session establishment, command processing, and execution result return. Receiving out-of-band management commands from an external device via the network, executing the out-of-band management commands to obtain execution results, and sending the execution results to the external device via the network may include:

[0121] S201. The first thread receives a request command through the connection socket interface with the external device and sends the request command to the second thread.

[0122] In this embodiment, the first thread (LANRECV) is responsible for receiving request commands sent from the network by the external device through the connection socket interface corresponding to the external device, and passing the commands to the second thread (LANHANDLER). The external device has already established a connection with the first operating system through this connection socket interface. Furthermore, after the external device has created the corresponding connection socket interface in the first operating system through interaction, it also needs to negotiate and establish a session with the first operating system through this connection socket interface, and send out-of-band server management commands in this session. Therefore, the aforementioned request command can be either a session establishment command or a server out-of-band management command. The session establishment command is the request command involved in negotiating and establishing the session. The specific request command receiving process of the first thread can be as follows:

[0123] Step 31: Use the first thread to determine whether the connection socket interface has been triggered. If the connection socket interface has been triggered, proceed to step 32; if the connection socket interface has not been triggered, proceed to step 31 after a preset sleep time.

[0124] In this step, the triggering of a connection socket interface signifies that an external device has sent network data packets to that interface. Therefore, the first operating system, when controlling the first thread, needs to monitor the triggering status of this connection socket interface to receive network data packets in a timely manner. Specifically, the aforementioned connection socket interfaces can be stored in a `recv` group (receive queue), which contains the connected socket interfaces. The first operating system can control the first thread to use the `FD_ISSET` function to determine whether the connection socket interfaces in the `recv` group have been triggered.

[0125] In addition, to reduce resource waste, when it is determined that the connection socket interface has not been triggered, the first thread can be controlled to re-enter step 31 after a preset sleep time. This embodiment does not limit the specific preset time; for example, it can be 1 millisecond.

[0126] Step 32: If the connection socket interface is triggered, the header of the network data packet sent by the external device is received through the connection socket interface, and it is determined whether the header was successfully received. If the header was successfully received, proceed to step 33; if the header was not successfully received, proceed to step 31 after a preset sleep time.

[0127] In this step, the first operating system can first receive the header of the network data packet through the first thread, and determine whether the header has been successfully received based on whether the header is complete. Since the header length is usually fixed, its completeness can be determined based on the length of the received header. In addition, considering network fluctuations, data reception may fail. In this case, to reduce resource waste, when it is determined that the header has not been successfully received, the first thread can be controlled to re-enter step 31 after a preset sleep time.

[0128] Step 33: If the data header is successfully received, continue to receive the request command in the network data packet through the connection socket interface, and determine whether the request command was successfully received. If the request command is successfully received, proceed to step 34; if the request command is not successfully received, proceed to step 31 after a preset sleep time.

[0129] In this step, the first operating system can continue to receive request commands from network data packets through the first thread, and determine whether the data header has been successfully received based on whether the request command is complete. The data header usually records the total length of the data packet, so the length of the request command can be determined based on the total length, and then its completeness can be determined based on the length of the received request command. In addition, considering network fluctuations, the request command may not be received successfully. In this case, to reduce resource waste, when it is determined that the request command has not been received successfully, the first thread can be controlled to re-enter step 31 after a preset sleep time.

[0130] Step 34: If the request command is successfully received, then send the request command to the second thread.

[0131] In this step, upon confirming successful reception of the request command, the first thread can be controlled to send the request command to the second thread for further processing. This embodiment does not limit how the first thread sends the request command to the second thread; it can be configured according to actual application requirements. Considering the large number of request commands, to facilitate sequential processing by the second thread, a message queue (LANRECVMSGQ) can be set up between the first and second threads, thereby allowing the first thread to control the sending of request commands to the second thread via the message queue.

[0132] Based on this, sending the request command to the second thread may include:

[0133] Step 41: Use the first thread to send the request command to the second thread via a message queue.

[0134] Furthermore, the first thread (LANRECV) can also be responsible for creating the aforementioned connection socket interface with external devices. The specific creation process is as follows:

[0135] Step 51: Use the first thread to determine whether the listening socket interface used to receive out-of-band management commands from the server is active; if the listening socket interface is active, proceed to step 52; if the listening socket interface is not active, exit.

[0136] In this step, the listening socket interface is used to receive and respond to network connection requests from external devices, and is typically bound to a corresponding network address (IP address) and port number. The first thread needs to use this listening socket interface to determine if an external device is connected. Therefore, if the first thread determines that the listening socket interface is active, it can continue with subsequent steps; if it determines that the listening socket interface is not active, it cannot determine the connection status of the external device and can exit.

[0137] Step 52: If the listening socket interface is activated, determine whether the listening socket interface has been triggered by the external device. If the listening socket interface has been triggered by the external device, proceed to step 53; if the listening socket interface has not been triggered by the external device, proceed to step 31.

[0138] The aforementioned listening socket interface can be stored in the accept group (access group), which stores socket interfaces used to access external devices; the first thread can be controlled to use the FD_ISSET function to determine whether the listening socket interface in the accept group is triggered.

[0139] Step 53: If the listening socket interface is triggered by the external device, set the listening socket interface to the accept state and create a connection socket interface corresponding to the external device.

[0140] In this step, if the listening socket interface is triggered by the external device, it means that the external device has been connected, and the first thread can then allocate the corresponding connection socket interface to the external device.

[0141] S202. The second thread determines the type of the request command. When the request command is determined to be a session establishment command, the session establishment command is processed to obtain session establishment response information, and the session establishment response information is sent to the fourth thread. Alternatively, when the request command is determined to be a server out-of-band management command, the server out-of-band management command is sent to the third thread.

[0142] In this embodiment, the second thread (LANHANDLER) is responsible for responding to session creation commands and sending session establishment response information to the fourth thread (LANSEND). The second thread is also responsible for sending server out-of-band management commands to the third thread (IPMIMSGHANDLER). Therefore, the second thread can be controlled to determine the type of the request command. If it is a session establishment command, it needs to be processed to obtain session establishment response information and then sent to the fourth thread; if it is a server out-of-band management command, it needs to be sent to the third thread.

[0143] It should be noted that this embodiment is not limited to a specific session creation command, and related technologies can be referenced. For example, the session creation command can be RMCP (Remote Management Control Protocol), RAKP (Remote Access Reference Architecture Key Pad Protocol), etc.

[0144] S203. The third thread executes the server out-of-band management command to obtain the execution result, and sends the execution result to the fourth thread.

[0145] In this embodiment, the third thread (LANHANDLER) is responsible for executing the server's out-of-band management commands, obtaining the execution results, and sending the results to the fourth thread (LANSEND). It should be noted that this embodiment does not limit how the third thread executes the server's out-of-band management commands, nor does it limit what kind of execution results it can produce. Related technologies can be referenced, such as those related to IPMI.

[0146] S204. The fourth thread sends the session establishment response information or the execution result to the external device through the connection socket interface.

[0147] In this embodiment, the fourth thread (LANHANDLER) sends session establishment response information or execution results to an external device via a connection socket interface. If a message queue is set up between the first and second threads, the fourth thread can be controlled to listen to this message queue and, upon retrieving the aforementioned session establishment response information or execution results from the message queue, send it to the external device.

[0148] Furthermore, both the first thread and the fourth thread can have corresponding thread activation identifiers. For example, the thread activation identifier for the first thread can be `gLanHandlerActive`, and the thread activation identifier for the second thread can be `gLanSendActive`. These thread activation identifiers correspond to either a first value or a second value. The first value is used to control thread operation, and the second value is used to control thread shutdown. For example, "1" controls thread operation, and "0" controls thread shutdown. Thus, when the first and fourth threads are not needed, their operation can be stopped by adjusting the corresponding thread activation identifiers.

[0149] Based on this, before receiving the request command through the connection socket interface with the external device using the first thread, the following may also be included:

[0150] Step 61: Determine the value of the first thread activation flag using the first thread;

[0151] Step 62: If the activation flag of the first thread is a first value, then proceed to the step of receiving request commands through the connection socket interface between the first thread and the external device.

[0152] Step 63: If the activation flag of the first thread is the second value, then destroy the first thread;

[0153] Before using the fourth thread to send the session establishment response information or the execution result to the external device through the connection socket interface, the method further includes:

[0154] Step 71: Use the fourth thread to determine the value of the second thread activation flag;

[0155] Step 72: If the activation flag of the second thread is the first value, then proceed to the step of using the fourth thread to send the session establishment response information or the execution result to the external device through the connection socket interface;

[0156] Step 73: If the activation flag of the second thread is the second value, then destroy the fourth thread.

[0157] As can be seen, by setting up the above four threads, the present invention can provide a lightweight mechanism for receiving and responding to out-of-band server management commands, thereby ensuring that the first operating system can temporarily replace the second operating system to receive and respond to commands, thus improving service quality.

[0158] Based on the above embodiments, when the first operating system receives and responds to out-of-band management commands from the server via the network, the right to receive and respond to these commands may specifically include network control and interface control (such as IPMI control) over the server's out-of-band management commands. Network control refers to control over the network interface card (NIC) device, and interface control refers to the right to receive and respond to the server's out-of-band management commands. The handover process for network control and interface control will be described below.

[0159] Based on this, transferring the right to receive and respond to out-of-band management commands from the server to the second operating system may include:

[0160] S301. The network control and the interface control are sequentially transferred to the second operating system. When the network control is transferred, the execution result is sent to the external device through the second operating system. When the interface control is transferred, the unprocessed out-of-band management commands of the server are sent to the second operating system.

[0161] In this embodiment, to ensure uninterrupted operation of existing tasks—that is, to ensure the first operating system can continue processing received but not yet completed out-of-band (OBB) management commands from the server—network control and interface control are sequentially transferred from the first operating system to the second operating system. The transfer order is: first, network control is transferred, and then interface control is transferred after the network control transfer is complete. Simultaneously, when network control has been transferred but interface control has not, the first operating system can send the execution result of the OBB management command to the second operating system, which then sends the execution result to an external device via the network interface card (NIC). Furthermore, when interface control has been transferred, the first operating system can send any unprocessed OBB management commands to the second operating system for continued processing. This allows for a smooth transition of network control and interface control without interrupting the response to OBB management commands.

[0162] Specifically, the network control and interface control are sequentially transferred to the second operating system. When the network control transfer is complete, the execution result is sent to the external device through the second operating system. When the interface control transfer is complete, any unexecuted out-of-band server management commands are sent to the second operating system. This may include:

[0163] Step 81: Stop receiving the server out-of-band management commands, cache unprocessed server out-of-band management commands, and continue to execute unprocessed server out-of-band management commands.

[0164] In this step, once the first operating system determines that the second operating system has completed initialization and is ready to begin the handover of permissions, it will stop receiving out-of-band management commands from the server and temporarily cache any unprocessed out-of-band management commands. It is worth noting that the first operating system can still continue to execute unprocessed out-of-band management commands at this time.

[0165] Step 82: Transfer network control to the second operating system.

[0166] Step 83: When the network control is transferred, the execution result is sent to the second operating system through the inter-core communication channel, so that the second operating system can send the execution result to the external device through the network.

[0167] In steps 82 and 83, the first operating system can transfer network control to the second operating system. After the transfer is successful, the first operating system will lose control of the network interface card (NIC), meaning that the first and fourth threads in the first operating system will be unable to function. To avoid interruption, the first operating system can treat the second operating system as a network proxy, sending the execution result to the second operating system via the inter-core communication channel, so that the latter can send the execution result to the external device via the network.

[0168] Step 84: Transfer the control of the interface to the second operating system.

[0169] Step 85: When the interface control is transferred, the unprocessed out-of-band server management commands are sent to the second operating system through the inter-core communication channel.

[0170] In steps 84 and 85, the first operating system can transfer interface control to the second operating system. After a successful transfer, the first operating system will no longer be able to execute server out-of-band management commands. To avoid interruption, the first operating system can treat the second operating system as an interface proxy and send any unprocessed server out-of-band management commands to the second operating system, allowing the latter to continue executing these commands. Once the server out-of-band management commands have been transmitted, the first operating system can determine that the transfer of control is complete.

[0171] As can be seen, this invention, through a smooth control handover mechanism, ensures stable and efficient processing of out-of-band management commands from the server at different stages of system operation. The first operating system handles the reception and processing of critical remote server out-of-band management commands during the initial startup phase, while the second operating system takes over after full startup, providing a more comprehensive command processing mechanism. This phased task processing approach not only improves system stability but also increases the reliability of the baseboard management controller when handling unexpected situations or high-load tasks.

[0172] Based on the above embodiments, after the first operating system transfers the right to receive and respond to out-of-band management commands from the server to the second operating system, it can enter the anomaly monitoring mode. The specific working content of the anomaly monitoring mode is described below.

[0173] Based on this, after transferring the right to receive and respond to the out-of-band management commands of the server to the second operating system, it may further include:

[0174] S401. Use the inter-core communication channel to detect whether the second operating system has encountered an anomaly.

[0175] S402. When it is determined that the second operating system has encountered an anomaly, the right to receive and respond to out-of-band management commands of the server is taken over.

[0176] In this embodiment, the first operating system can also use the inter-core communication channel to detect whether the second operating system is encountering an anomaly. For example, the second operating system can periodically send heartbeat signals to the first operating system through the inter-core communication channel, and the latter can determine whether the former is working normally based on the heartbeat signals. If the first operating system determines that the second operating system is encountering an anomaly and cannot respond to out-of-band management commands from the server, it will immediately take over the aforementioned response receiving permissions to continue command response, thereby ensuring service quality.

[0177] Based on the above embodiments, another command processing method provided in this embodiment will be described below. For ease of understanding, please refer to... Figure 2 , Figure 2 The flowchart illustrates another command processing method provided in an embodiment of the present invention. This method is applied to a second operating system in a baseboard management controller. The baseboard management controller further includes a first operating system, the first operating system having a higher response speed than the second operating system. The method may include:

[0178] S501. When the baseboard management controller triggers the startup operation, a system initialization operation is performed, and an inter-core communication channel is established with the first operating system. The startup operation is used to trigger both the first operating system and the second operating system to perform the system initialization operation. When the first operating system determines that it has completed initialization, it receives and responds to the out-of-band management command from the server, and determines whether the second operating system has completed initialization through the inter-core communication channel.

[0179] In this step, when the baseboard management controller triggers the boot operation, it can trigger both the first operating system and the second operating system to perform system initialization operations. Additionally, during the boot process, the first operating system needs to establish an inter-core communication channel with the second operating system. The first operating system can determine whether the second operating system has completed initialization through this inter-core communication channel. For example, the first operating system can send an initialization status query request to the second operating system through this channel and determine whether the second operating system has completed initialization based on the second operating system's response; alternatively, the second operating system can proactively send initialization completion information to the first operating system upon completion, so that the latter can confirm that the former has completed initialization.

[0180] S502. Upon determining that it has completed initialization, it receives the right to receive out-of-band management commands from the first operating system.

[0181] In this step, upon confirming the completion of its initialization, the second operating system can hand over the right to receive and respond to out-of-band (OB) management commands from the first operating system. As mentioned above, when responding to commands sent by external devices via the network, this right to receive and respond can include network control and interface control. To ensure that existing tasks are not interrupted, i.e., to ensure that the first operating system can continue to process the OB commands it has received but not yet completed, the network control and interface control are sequentially transferred from the first operating system to the second operating system. The transfer order is: first, network control is transferred, and then interface control is transferred after the network control transfer is complete. Simultaneously, when network control has been transferred but interface control has not, the first operating system can send the execution result of the OB commands to the second operating system, which then sends the execution result to the external device via the network interface card (NIC). Additionally, when interface control has been transferred, the first operating system can send any unprocessed OB commands to the second operating system for continued processing. In this way, a smooth transition of network control and interface control can be achieved without interrupting the response to OB commands.

[0182] Based on this, the right to receive a response includes network control rights and interface control rights for the server's out-of-band management commands; the right to receive a response to the server's out-of-band management commands transferred by the first operating system may include:

[0183] Step 91: Sequentially receive network control and interface control transferred by the first operating system. When the network control is transferred, receive the execution result of the server out-of-band management command sent by the first operating system and send it to the corresponding external device through the network. When the interface control receives the unprocessed server out-of-band management command sent by the first operating system, continue to execute it.

[0184] Specifically, step 91 may include:

[0185] Step 1001: Receive network control transferred from the first operating system;

[0186] Step 1002: When the network control is transferred, the execution result sent by the second operating system is received through the inter-core communication channel, and the execution result is sent to the external device through the network.

[0187] In steps 1001 and 1002, the first operating system can transfer network control to the second operating system. After the transfer is successful, the first operating system will lose control of the network interface card (NIC), meaning that the first and fourth threads in the first operating system will be unable to function. To avoid interruption, the first operating system can treat the second operating system as a network proxy, sending the execution result to the second operating system via the inter-core communication channel, so that the latter can send the execution result to the external device via the network.

[0188] Step 1003: Receive interface control transferred from the first operating system;

[0189] Step 1004: When the interface control is transferred, receive the unprocessed out-of-band server management command sent by the first operating system through the inter-core communication channel, and continue to execute the unprocessed out-of-band server management command.

[0190] In steps 1003 and 1004, the first operating system can transfer interface control to the second operating system. After a successful transfer, the first operating system will no longer be able to execute server out-of-band management commands. To avoid interruption, the first operating system can treat the second operating system as an interface proxy and send any unprocessed server out-of-band management commands to the second operating system, so that the latter can continue to execute these server out-of-band management commands.

[0191] S503. When the right to receive the response is completed, receive and respond to the server's out-of-band management command.

[0192] In this step, after receiving the response right, the second operating system can continue to receive and respond to the server's out-of-band management commands according to the original process.

[0193] Based on the above embodiments, the command processing method described above will be described in detail below with specific examples. This embodiment will elaborate on the method of the baseboard management controller to quickly respond to remote IPMI commands based on the real-time operating system from three aspects: system architecture, command processing flow, and handover of response rights.

[0194] 1. IPMI System Architecture:

[0195] Figure 3 This invention demonstrates the IPMI system architecture provided by this invention. The baseboard management controller includes a main processor and a co-processor. The main processor runs a complete Linux system (non-real-time operating system), which includes an IPMI daemon, IPMI drivers, a network protocol stack, and a Linux kernel. The Linux operating system can communicate with the BIOS (Basic Input / Output System) via the KCS channel to process IPMI commands from the local machine. The Linux operating system can also communicate with remote clients via the NIC (Network Interface Card) to process remote IPMI commands from the network. The co-processor runs a lightweight real-time operating system (RTOS), which includes lightweight IPMI tasks (threads), TCP / IP and UDP / IP protocol stacks, and an RTOS kernel. The real-time operating system can typically boot within 5 seconds and can also control the NIC and KCS channel. In scenarios where the host powers on immediately, it can quickly communicate with the BIOS and respond rapidly to IPMI requests from remote clients. A software-implemented logical MUX (multiplexer) enables the switching of control over the NIC and IPMI command response (interface control) between the operating systems running on the main processor and coprocessors. Once Linux boots, the IPMI command reception and response responsibility switches to the Linux system on the main processor, which provides richer IPMI command processing capabilities. The entire design ensures that the board management controller can respond quickly to IPMI commands after power-on, while continuing to provide comprehensive management functions after the Linux system has fully booted.

[0196] Real-time operating systems and Linux should both have the ability to receive and process local IPMI commands (KCS channel) and remote IPMI commands (NIC). The method provided in this invention focuses on the design of the processing flow for remote IPMI commands.

[0197] 2. Design of IPMI command processing flow for real-time operating system:

[0198] Figure 4This invention demonstrates the IPMI processing flow on the real-time operating system side. After system power-on, the real-time operating system (RTOS) starts first and immediately performs network initialization and IPMI initialization. These two steps ensure that the ROS can quickly respond to IPMI requests from a remote location. Simultaneously, the ROS establishes an inter-kernel communication channel with the Linux system to receive its status signals after Linux has booted. Once Linux has booted, the ROS begins to gradually hand over IPMI response control to Linux. First, the ROS can hand over network control, entering the IPMI proxy phase, followed by the handover of IPMI interface control. The specific handover process will be described in detail in subsequent chapters. After the handover is complete, the ROS enters an anomaly monitoring state so that it can quickly regain control of the network and IPMI in the event of an anomaly in Linux.

[0199] In the method proposed in this invention, the real-time operating system will create four Task threads and two message queues to implement the remote IPMI command response function, as shown in Tables 1 and 2.

[0200] Table 1. Real-time Operating System IPMI Processing Task Threads

[0201]

[0202] Table 2 IPMI Message Queues for Real-Time Operating Systems

[0203]

[0204] The `kcsSend` function described above is used to send the execution results of IPMI commands to the KCS interface; its specific workflow will not be described in detail. In the Task thread running on the real-time operating system, `LANHANDLER` and `IPMIMSGHANDLER` are responsible for executing IPMI commands, and their interaction process is as follows: Figure 5 As shown. In this process, the RMCP+RAP protocol is first processed to create a session, and then remote IPMI commands are received and executed.

[0205] The execution flow of remote IPMI commands is as follows: Figure 6As shown, this process is executed by LANHANDLER. First, it checks if gLanHandlerActive (the first thread activation flag) is 1. If it is, the process continues; otherwise, it ends. Next, it listens to the lanRecvMsgQ message queue (the first message queue). Upon receiving data, it checks if the command is related to session creation. If it is, the system directly processes it and returns the data to lanSendMsgQ (the third message queue); otherwise, it sends the data to the ipmiHandlerMsgQ message queue (the second message queue) for further processing by ipmiMsgHandler.

[0206] In the Task running on the real-time operating system, lanRecv is responsible for creating sockets and receiving network data. Its receiving process is as follows: Figure 7 As shown. First, check if there is an active IPMI remote command receive socket. If not, the process ends. If there is, use the FD_ISSET method to check if there is a socket in the accept group (access group) in an acceptable state. When the socket is triggered, the socket will be accepted and added to the recv group (receive group, also known as the receive queue). Next, use FD_ISSET to check if there is IPMI command data to be received in the socket in the recv group. If the socket is detected to be triggered, attempt to receive the header length data (usually used to determine the size of the entire packet) from the socket. Then, determine if the IPMI header length has been successfully received. If successful, continue to receive IPMI commands and determine if the entire command has been received. Once the reception is complete, the command will be placed in the processing queue (lanIfCTaskMsgQ) for subsequent processing. If the socket is not triggered or reception fails at any step, the system will enter a sleep state (sleep(1)) and then restart the detection.

[0207] In the Task running on the real-time operating system, LANSEND is responsible for sending the results of IPMI command execution to the Socket. The process of sending IPMI results is as follows: Figure 8 As shown. First, it checks if the global variable gLanSendActive (the second thread activation flag) is 1. If it is, it continues with subsequent operations; otherwise, it destroys the thread. Next, the system blocks and listens to the lanRecvMsgQ message queue (the first message queue). Upon receiving data, it unblocks and sends the data to the Socket via the Send interface. Finally, the process repeats.

[0208] 3. IPMI control handover design:

[0209] The method for rapid response of the real-time operating system on the baseboard management controller to remote IPMI commands proposed in this invention involves the handover process of IPMI control from the real-time operating system to Linux as follows: Figure 9 As shown in the diagram, after Linux boots up, the system notifies the real-time operating system (RTOS) via inter-kernel communication. The ROS then prepares to hand over IPMI control, pausing IPMI command reception and temporarily storing unfinished IPMI commands. Subsequently, network control is transferred from the ROS to Linux. Linux can receive new IPMI commands, but since it does not yet have the ability to execute them, it temporarily stores the received commands. The ROS continues to execute IPMI commands and sends the execution results to Linux via inter-kernel communication, which then forwards them to the network socket via Linux's network proxy. Afterward, the ROS transfers IPMI execution control to Linux, which now has the authority to receive and execute IPMI commands and begins executing the temporarily stored commands. The ROS then needs to complete the execution of the remaining IPMI commands. Since control has been transferred, the ROS sends the commands to Linux via inter-kernel communication for IPMI proxy execution, which Linux then performs. Once the ROS has processed all remaining IPMI commands, the entire handover process is complete, and Linux is responsible for receiving, executing, and sending subsequent IPMI commands.

[0210] During the handover process, by gradually transferring control, the transition of IPMI control from the real-time operating system to Linux can be completed without interrupting existing tasks.

[0211] The command processing apparatus, board management controller, server, computer program product, and computer-readable storage medium provided in the embodiments of the present invention will be described below. The command processing apparatus, board management controller, server, computer program product, and computer-readable storage medium described below can be referred to in correspondence with the command processing method described above.

[0212] Please refer to Figure 10 , Figure 10 This is a structural block diagram of a command processing device provided in an embodiment of the present invention. The device is applied to a first operating system in a baseboard management controller. The baseboard management controller further includes a second operating system. The response speed of the first operating system is higher than that of the second operating system. The device includes:

[0213] The initialization module 1001 is used to perform system initialization operations and establish an inter-core communication channel with the second operating system when the baseboard management controller triggers a startup operation; the startup operation is used to trigger both the first operating system and the second operating system to perform the system initialization operation.

[0214] The command receiving and response module 1002 is used to receive and respond to out-of-band management commands from the server when it determines that it has completed initialization.

[0215] The judgment module 1003 is used to determine whether the second operating system has completed initialization using the inter-core communication channel;

[0216] The handover module 1004 is used to transfer the right to receive and respond to the server out-of-band management command to the second operating system when it is determined that the second operating system has completed initialization, so that the second operating system can receive and respond to the server out-of-band management command.

[0217] Optionally, the command receiving response module 1002 can be used for:

[0218] The system receives out-of-band management commands from external devices via the network, executes the out-of-band management commands to obtain execution results, and then sends the execution results back to the external devices via the network.

[0219] Optionally, the real-time operating system includes a first thread, a second thread, a third thread, and a fourth thread; the command receiving and response module 1002 may include:

[0220] The first thread module is used to receive a request command through the connection socket interface with the external device and send the request command to the second thread.

[0221] The second thread module is used to determine the type of the request command using the second thread. When the request command is determined to be a session establishment command, the module processes the session establishment command to obtain session establishment response information and sends the session establishment response information to the fourth thread. Alternatively, when the request command is determined to be a server out-of-band management command, the module sends the server out-of-band management command to the third thread.

[0222] The third thread module is used to execute the server out-of-band management command using the third thread, obtain the execution result, and send the execution result to the fourth thread;

[0223] The fourth thread module is used to send the session establishment response information or the execution result to the external device through the connection socket interface.

[0224] Optionally, the first thread module can also be used for:

[0225] The first thread is used to determine whether the connection socket interface has been triggered.

[0226] If the connection socket interface is triggered, the header of the network data packet sent by the external device is received through the connection socket interface, and it is determined whether the header has been successfully received.

[0227] If the data header is successfully received, the request command in the network data packet will continue to be received through the connection socket interface, and it will be determined whether the request command has been successfully received.

[0228] If the request command is successfully received, the request command is sent to the second thread.

[0229] Optionally, the first thread module can also be used for:

[0230] The first thread is used to determine whether the listening socket interface used to receive out-of-band management commands from the server is active.

[0231] If the listening socket interface is already active, then determine whether the listening socket interface has been triggered by the external device.

[0232] If the listening socket interface is triggered by the external device, the listening socket interface is set to the accept state, and a connection socket interface corresponding to the external device is created.

[0233] Optionally, the first thread module can also be used for:

[0234] The first thread sends the request command to the second thread via a message queue.

[0235] Optionally, the first thread module can also be used for:

[0236] The value of the first thread activation flag is determined using the first thread;

[0237] If the activation flag of the first thread is a first value, then proceed to the step of receiving request commands through the connection socket interface between the first thread and the external device.

[0238] If the activation flag of the first thread is the second value, then the first thread is destroyed;

[0239] The fourth thread module can also be used for:

[0240] The value of the activation flag of the second thread is determined using the fourth thread;

[0241] If the activation flag of the second thread is the first value, then proceed to the step of using the fourth thread to send the session establishment response information or the execution result to the external device through the connection socket interface;

[0242] If the activation flag of the second thread is the second value, then the fourth thread is destroyed.

[0243] Optionally, the right to receive a response includes network control rights and interface control rights for the server's out-of-band management commands; the handover module 1004 can be used for:

[0244] The network control and the interface control are sequentially transferred to the second operating system. When the network control is transferred, the execution result is sent to the external device through the second operating system. When the interface control is transferred, the unprocessed out-of-band management commands of the server are sent to the second operating system.

[0245] Optionally, the handover module 1004 may include:

[0246] The handover initialization submodule is used to stop receiving the server out-of-band management commands, cache unprocessed server out-of-band management commands, and continue to execute unprocessed server out-of-band management commands.

[0247] The first handover submodule is used to transfer network control to the second operating system;

[0248] The forwarding submodule is used to send the execution result to the second operating system through the inter-core communication channel when the network control is transferred, so that the second operating system can send the execution result to the external device through the network;

[0249] The second handover submodule is used to hand over the interface control to the second operating system;

[0250] The command handover submodule is used to send unprocessed out-of-band server management commands to the second operating system through the inter-core communication channel when the interface control is handed over.

[0251] Optionally, the command receiving response module 1002 can be used for:

[0252] The system receives out-of-band server management commands from the local user via a serial communication interface, executes the out-of-band server management commands to obtain execution results, and outputs the execution results via the serial communication interface.

[0253] Optionally, the device may further include:

[0254] An anomaly detection module is used to detect whether the second operating system has encountered an anomaly using the inter-core communication channel;

[0255] The takeover module is used to take over the right to receive and respond to out-of-band management commands from the server when it is determined that the second operating system has encountered an anomaly.

[0256] Please refer to Figure 11 , Figure 11 This is a structural block diagram of another command processing device provided in an embodiment of the present invention. The device is applied to a second operating system in a baseboard management controller. The baseboard management controller further includes a first operating system, the first operating system having a higher response speed than the second operating system. The device includes:

[0257] The initialization module 1101 is used to perform a system initialization operation and establish an inter-core communication channel with the first operating system when the baseboard management controller triggers a startup operation; the startup operation is used to trigger both the first operating system and the second operating system to perform the system initialization operation; when the first operating system determines that it has completed initialization, it receives and responds to the out-of-band management command from the server, and determines whether the second operating system has completed initialization through the inter-core communication channel;

[0258] The handover module 1102 is used to receive the right to receive out-of-band management commands from the server handed over by the first operating system when it determines that it has completed initialization;

[0259] The command receiving and response module 1103 is used to receive and respond to the server's out-of-band management command when the receiving response right is completed.

[0260] Optionally, the right to receive a response includes network control rights and interface control rights for the server's out-of-band management commands; the handover module 1102 can be used for:

[0261] The system sequentially receives network control and interface control transferred from the first operating system. When the network control is transferred, it receives the execution result of the server out-of-band management command sent by the first operating system and sends it to the corresponding external device via the network. When the interface control receives the unprocessed server out-of-band management command sent by the first operating system, it continues to execute it.

[0262] Optionally, the handover module 1102 may include:

[0263] The first handover submodule is used to receive network control transferred by the first operating system;

[0264] The network proxy submodule is used to receive the execution result sent by the second operating system through the inter-core communication channel when the network control is transferred, and to send the execution result to the external device through the network.

[0265] The second handover submodule is used to receive the interface control rights transferred by the first operating system;

[0266] The command handover submodule is used to receive unprocessed out-of-band server management commands sent by the first operating system through the inter-core communication channel when the interface control is handed over, and to continue executing the unprocessed out-of-band server management commands.

[0267] Please refer to Figure 12 , Figure 12 This is a structural block diagram of a baseboard management controller provided in an embodiment of the present invention. The embodiment of the present invention provides a baseboard management controller 10, including a processor 11 and a memory 12; wherein, the memory 12 is used to store operating system programs of a first operating system and operating system programs of a second operating system; the processor 11 is used to execute a command processing method applied to the first operating system when loading the operating system program of the first operating system, or to execute a command processing method applied to the second operating system when loading the operating system program of the second operating system.

[0268] For details regarding the specific process of the above command processing method, please refer to the corresponding content provided in the foregoing embodiments, which will not be repeated here.

[0269] In addition, the processor 11 may also include a main processor and a coprocessor, wherein the main processor runs the second operating system and the coprocessor runs the first operating system.

[0270] In addition, the memory 12, as a carrier for resource storage, can be a read-only memory, random access memory, disk, or optical disk, and the storage method can be temporary storage or permanent storage.

[0271] In addition, the substrate management controller 10 also includes a power supply 13, a communication interface 14, an input / output interface 15, and a communication bus 16. The power supply 13 provides operating voltage to the various hardware devices on the substrate management controller 10. The communication interface 14 creates a data transmission channel between the substrate management controller 10 and external devices; it can be a network port, serial communication interface, etc., and the communication protocol it follows can be any communication protocol applicable to the technical solution of this invention, without specific limitations. The input / output interface 15 is used to acquire external input data or output data to the outside world; its specific interface type can be selected according to specific application needs, without specific limitations.

[0272] This invention also provides a server, including the baseboard management controller described above.

[0273] Since the embodiments of the server part correspond to the embodiments of the command processing method part, please refer to the above description for the embodiments of the server part, and will not be repeated here.

[0274] This invention also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the command processing method described in the above embodiments.

[0275] Since the embodiments of the computer program product portion correspond to the embodiments of the command processing method portion, please refer to the description of the embodiments of the command processing method portion for the embodiments of the computer program product portion, and will not be repeated here.

[0276] This invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the command processing method described in the above embodiments.

[0277] Since the embodiments of the computer-readable storage medium portion correspond to the embodiments of the command processing method portion, the embodiments of the storage medium portion are described in the description of the embodiments of the command processing method portion, and will not be repeated here.

[0278] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0279] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0280] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0281] The foregoing has provided a detailed description of the command processing method, apparatus, baseboard management controller, server, computer program product, and computer-readable storage medium provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of the present invention. It should be noted that those skilled in the art can make various improvements and modifications to the present invention without departing from its principles, and these improvements and modifications also fall within the protection scope of the present invention.

Claims

1. A command processing method, characterized in that, A first operating system applied in a baseboard management controller, the baseboard management controller further comprising a second operating system, wherein the first operating system has a higher response speed than the second operating system, the method comprising: When the baseboard management controller triggers a startup operation, it performs a system initialization operation and establishes an inter-core communication channel with the second operating system; the startup operation is used to trigger both the first operating system and the second operating system to perform the system initialization operation. Upon confirming that it has completed initialization, it receives and responds to out-of-band management commands from the server via the network. The inter-core communication channel is used to determine whether the second operating system has completed initialization; When the second operating system completes initialization, network control and interface control of the server out-of-band management commands are sequentially transferred to the second operating system. When the network control is transferred, the execution result is sent to the external device through the second operating system, and the server out-of-band management request sent by the external device is temporarily stored through the second operating system. When the interface control is transferred, the unprocessed server out-of-band management commands are sent to the second operating system so that the second operating system can receive and respond to the server out-of-band management commands. The first operating system includes a first thread, a second thread, a third thread, and a fourth thread; Receive and respond to out-of-band management commands from the server over the network, including: The first thread creates a connection socket interface with the external device, receives request commands through the connection socket interface with the external device, and sends the request commands to the second thread. The second thread determines the type of the request command. If the request command is determined to be a session establishment command, the session establishment command is processed to obtain session establishment response information, and the session establishment response information is sent to the fourth thread. Alternatively, if the request command is determined to be a server out-of-band management command, the server out-of-band management command is sent to the third thread. In this case, the external device and the first operating system first negotiate to establish a session, and then send the server out-of-band management command in the session. The third thread executes the out-of-band management command of the server to obtain the execution result, and then sends the execution result to the fourth thread; The fourth thread uses the connection socket interface to send the session establishment response information or the execution result to the external device.

2. The command processing method according to claim 1, characterized in that, The first thread receives a request command through a connection socket interface with the external device and sends the request command to the second thread, including: The first thread is used to determine whether the connection socket interface has been triggered. If the connection socket interface is triggered, the header of the network data packet sent by the external device is received through the connection socket interface, and it is determined whether the header has been successfully received. If the data header is successfully received, the request command in the network data packet will continue to be received through the connection socket interface, and it will be determined whether the request command has been successfully received. If the request command is successfully received, the request command is sent to the second thread.

3. The command processing method according to claim 2, characterized in that, Before using the first thread to determine whether the connection socket interface has been triggered, the method further includes: The first thread is used to determine whether the listening socket interface used to receive out-of-band management commands from the server is active. If the listening socket interface is already active, then determine whether the listening socket interface has been triggered by the external device. If the listening socket interface is triggered by the external device, the listening socket interface is set to the accept state, and a connection socket interface corresponding to the external device is created.

4. The command processing method according to claim 1, characterized in that, Sending the request command to the second thread includes: The first thread sends the request command to the second thread via a message queue.

5. The command processing method according to claim 1, characterized in that, Before receiving request commands via the connection socket interface with the external device using the first thread, the method further includes: The value of the first thread activation flag is determined using the first thread; If the activation flag of the first thread is a first value, then proceed to the step of receiving request commands through the connection socket interface between the first thread and the external device. If the activation flag of the first thread is the second value, then the first thread is destroyed; Before using the fourth thread to send the session establishment response information or the execution result to the external device through the connection socket interface, the method further includes: The value of the activation flag of the second thread is determined using the fourth thread; If the activation flag of the second thread is the first value, then proceed to the step of using the fourth thread to send the session establishment response information or the execution result to the external device through the connection socket interface; If the activation flag of the second thread is the second value, then the fourth thread is destroyed.

6. The command processing method according to claim 1, characterized in that, The network control and interface control are sequentially transferred to the second operating system. Upon completion of the network control transfer, the execution result is sent to the external device via the second operating system. Upon completion of the interface control transfer, unexecuted out-of-band server management commands are sent to the second operating system, including: Stop receiving the server out-of-band management commands, cache unprocessed server out-of-band management commands, and continue to execute unprocessed server out-of-band management commands; The network control is transferred to the second operating system; When the network control is transferred, the execution result is sent to the second operating system through the inter-core communication channel, so that the second operating system can send the execution result to the external device through the network; The interface control is transferred to the second operating system; When the interface control is transferred, any unprocessed out-of-band server management commands are sent to the second operating system through the inter-core communication channel.

7. The command processing method according to claim 1, characterized in that, Receive and respond to out-of-band management commands from the server, including: The system receives out-of-band server management commands from the local user via a serial communication interface, executes the out-of-band server management commands to obtain execution results, and outputs the execution results via the serial communication interface.

8. The command processing method according to claim 1, characterized in that, After transferring the right to receive and respond to the out-of-band management commands of the server to the second operating system, the process also includes: The inter-core communication channel is used to detect whether the second operating system is encountering an anomaly. When it is determined that the second operating system has encountered an anomaly, the right to receive and respond to out-of-band management commands from the server is taken over.

9. A command processing method, characterized in that, A second operating system applied in a baseboard management controller, the baseboard management controller further comprising a first operating system, the first operating system having a higher response speed than the second operating system, the method comprising: When the baseboard management controller triggers a startup operation, it performs a system initialization operation and establishes an inter-core communication channel with the first operating system. The startup operation triggers both the first and second operating systems to perform the system initialization operation. When the first operating system determines that it has completed initialization, it receives and responds to out-of-band management commands from the server and determines whether the second operating system has completed initialization through the inter-core communication channel. The first operating system includes a first thread, a second thread, a third thread, and a fourth thread. The first thread is used to create a connection socket interface with an external device, receive request commands through the connection socket interface with the external device, and send the request commands to the second thread. The second thread is used for... The system determines the type of request command sent by the external device. If the request command is determined to be a session establishment command, it processes the session establishment command to obtain session establishment response information and sends the session establishment response information to the fourth thread. Alternatively, if the request command is determined to be a server out-of-band management command, it sends the server out-of-band management command to the third thread. The third thread executes the server out-of-band management command to obtain an execution result and sends the execution result to the fourth thread. The fourth thread sends the session establishment response information or the execution result to the external device through the connection socket interface. The external device and the first operating system first negotiate to establish a session, and then send the server out-of-band management command in the session. Upon determining that it has completed initialization, it sequentially receives network control and interface control of the server out-of-band management command from the first operating system. When the network control is transferred, it receives the execution result of the server out-of-band management command sent by the first operating system and sends it to the corresponding external device through the network, and temporarily stores the server out-of-band management request sent by the external device. When the interface control is transferred, it receives the unprocessed server out-of-band management command sent by the first operating system and continues to execute it.

10. The command processing method according to claim 9, characterized in that, The system sequentially receives network control and interface control transferred from the first operating system. Upon completion of the network control transfer, it receives the execution result of the out-of-band server management command sent by the first operating system and transmits it to an external device via the network. Upon completion of the interface control transfer, it receives and continues to execute any unprocessed out-of-band server management commands sent by the first operating system, including: Receive network control transferred from the first operating system; When the network control is transferred, the execution result sent by the second operating system is received through the inter-core communication channel, and the execution result is sent to the external device through the network; Receive interface control transferred from the first operating system; When the interface control is handed over, the system receives the unprocessed out-of-band server management commands sent by the first operating system through the inter-core communication channel and continues to execute the unprocessed out-of-band server management commands.

11. A command processing device, characterized in that, A first operating system applied in a baseboard management controller, the baseboard management controller further comprising a second operating system, the first operating system having a higher response speed than the second operating system, the device comprising: An initialization module is used to perform system initialization operations and establish an inter-core communication channel with the second operating system when the baseboard management controller triggers a startup operation; the startup operation is used to trigger both the first operating system and the second operating system to perform the system initialization operation; The command receiving and response module is used to receive and respond to out-of-band management commands from the server over the network when it determines that it has completed initialization. The judgment module is used to determine whether the second operating system has completed initialization using the inter-core communication channel; The handover module is used to, when the second operating system completes initialization, sequentially transfer network control and interface control of the server out-of-band management commands to the second operating system; when the network control is transferred, send the execution result to the external device through the second operating system; temporarily store the server out-of-band management requests sent by the external device through the second operating system; and when the interface control is transferred, send the unprocessed server out-of-band management commands to the second operating system so that the second operating system can receive and respond to the server out-of-band management commands. The first operating system includes a first thread, a second thread, a third thread, and a fourth thread; The command receiving and response module includes: The first thread module is used to create a connection socket interface with the external device using the first thread, receive request commands through the connection socket interface with the external device, and send the request commands to the second thread; The second thread module is used to determine the type of the request command using the second thread. When the request command is determined to be a session establishment command, the module processes the session establishment command to obtain session establishment response information and sends the session establishment response information to the fourth thread. Alternatively, when the request command is determined to be a server out-of-band management command, the module sends the server out-of-band management command to the third thread. The external device and the first operating system first negotiate to establish a session, and then send the server out-of-band management command in the session. The third thread module is used to execute the server out-of-band management command using the third thread, obtain the execution result, and send the execution result to the fourth thread; The fourth thread module is used to send the session establishment response information or the execution result to the external device through the connection socket interface.

12. A command processing device, characterized in that, A second operating system for use in a baseboard management controller, the baseboard management controller further comprising a first operating system, the first operating system having a higher response speed than the second operating system, the device comprising: An initialization module is used to perform system initialization operations and establish an inter-core communication channel with the first operating system when the baseboard management controller triggers a startup operation. The startup operation is used to trigger both the first and second operating systems to perform the system initialization operation. When the first operating system determines that it has completed initialization, it receives and responds to out-of-band management commands from the server and determines whether the second operating system has completed initialization through the inter-core communication channel. The first operating system includes a first thread, a second thread, a third thread, and a fourth thread. The first thread is used to create a connection socket interface with an external device, receive request commands through the connection socket interface with the external device, and send the request commands to the second thread. A thread is used to determine the type of request command sent by an external device. If the request command is determined to be a session establishment command, the thread processes the session establishment command to obtain session establishment response information and sends the session establishment response information to the fourth thread. Alternatively, if the request command is determined to be a server out-of-band management command, the thread sends the server out-of-band management command to the third thread. The third thread executes the server out-of-band management command to obtain an execution result and sends the execution result to the fourth thread. The fourth thread sends the session establishment response information or the execution result to the external device through the connection socket interface. The external device and the first operating system first negotiate to establish a session, and then send the server out-of-band management command within the session. The handover module is used to receive, in sequence, the network control rights transferred by the first operating system and the interface control rights of the server's out-of-band management commands when it determines that it has completed initialization. The command receiving and response module is used to receive the execution result of the server out-of-band management command sent by the first operating system when the network control is handed over and send it to the corresponding external device through the network, and temporarily store the server out-of-band management request sent by the external device. When the interface control is handed over, it receives the unprocessed server out-of-band management command sent by the first operating system and continues to execute it.

13. A baseboard management controller, characterized in that, include: Memory, used to store the operating system program of the first operating system and the operating system program of the second operating system; A processor is configured to execute the command processing method according to any one of claims 1 to 8 when loading the operating system program of the first operating system, or to execute the command processing method according to any one of claims 9 to 10 when loading the operating system program of the second operating system.

14. The baseboard management controller according to claim 13, characterized in that, The processor includes a main processor and a coprocessor, the main processor running the second operating system and the coprocessor running the first operating system.

15. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by the processor, they implement the command processing method according to any one of claims 1 to 8 or the command processing method according to any one of claims 9 to 10.

16. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when loaded and executed by a processor, implement the command processing method according to any one of claims 1 to 8 or the command processing method according to any one of claims 9 to 10.

Images