A communication method and server

Abstract

The embodiment of the application provides a communication method and a server, and relates to the technical field of servers.The method comprises the following steps: receiving, by an extension driver, a first access message of first service software to a target device, the extension driver being a driver for realizing communication between the first service software and the target device, the first service software running on a BMC; applying, by the extension driver, to a common driver for obtaining a structure pointer of the target device, the common driver being a driver for realizing communication between second service software and the target device, the structure pointer being associated with address information of the target device, and the second service software being capable of running on the BMC; exporting, by the extension driver, a function required for accessing the target device from the common driver; and transmitting, by the extension driver, the first access message to the target device by using the function according to the address information associated with the structure pointer.Thus, the normalization deployment of drivers required by different service software is achieved through the common driver, and the maintenance cost is reduced without differentiated provision of function and data structure and other driver implementation modes.

Description

Technical Field

[0001] This application relates to the field of server technology, and in particular to a communication method and a server. Background Technology

[0002] The server's baseboard management controller (BMC) chip runs business software (also known as the "BMC management software system"). The BMC business software can communicate with the various peripheral organization management controllers (SMCs) on the intelligent platform management bus (IPMB) through drivers, thereby controlling the corresponding hardware.

[0003] Currently, there are many BMC (Business Controller) application software programs used in the industry. Because these different BMC application software programs have different functional requirements, it is usually necessary to provide corresponding IPMB drivers for each. These BMC application software programs are highly coupled with their respective IPMB driver interfaces to meet the varying requirements of the BMC application software regarding the IPMB driver interface, specific implementation methods, and data structures passed between them, in order to access the hardware. However, this results in high maintenance costs for server operators who need to maintain multiple IPMB drivers for each different BMC application software in scenarios where the server needs to run multiple different BMC application software programs. Summary of the Invention

[0004] This application provides a communication method, device, server, computer storage medium, and computer program product that can reduce driver maintenance costs.

[0005] In a first aspect, embodiments of this application provide a communication method, the method comprising: receiving a first access message from a first service software to a target device via an extended driver, wherein the extended driver is a driver program for implementing communication between the first service software and the target device, and the first service software runs on a Baseboard Management Controller (BMC); requesting a structure pointer of the target device from a common driver via the extended driver, wherein the common driver is a driver program for implementing communication between a second service software and the target device, the structure pointer being associated with address information of the target device, and the second service software being able to run on the BMC; deriving a function required to access the target device from the common driver via the extended driver; and using the function to transmit the first access message to the target device according to the address information associated with the structure pointer via the extended driver.

[0006] In this embodiment, different business software (i.e., BMC management software system) can run on the BMC on the server. Each business software can communicate with the server hardware (e.g., processor, memory, fan, etc.) through the IPMB controller on the BMC. The IPMB controller can provide corresponding IPMB interfaces for these hardware components of the server. These IPMB interfaces can be implemented through the register groups on the IPMB controller. In other words, the business software can communicate with the corresponding hardware by accessing the register groups (i.e., target devices) on the PMB controller through the driver. Therefore, in this embodiment, the driver of one business software (i.e., the second business software) deployed on the BMC is used as a common driver, uniformly providing the structure pointers and functions required to access the target device for the drivers of other business software (i.e., the first business software) on the BMC (i.e., extended drivers). In this way, it is no longer necessary to provide a separate set of functions and data structures for each extended driver, which can realize communication between the software layer and the server hardware layer, greatly reducing the maintenance cost of the driver.

[0007] In some possible implementations, the method further includes: obtaining the second access message of the second business software to the target device through the public driver; obtaining the structure pointer of the target device through the public driver; calling the function required to access the target device through the public driver; and using the function to pass the second access message to the target device according to the address information associated with the structure pointer through the public driver.

[0008] In this way, in addition to providing the necessary functions and structure pointers for the extended drivers of other business software, the public driver can also provide functions and structure pointers for its own business software (i.e., the second business software), enabling the second business software to communicate with the server hardware layer.

[0009] In some possible implementations, before receiving the first access message from the first business software to the target device, the method includes: assigning a device number to the target device through a common driver; defining a device structure for the target device, which includes a structure pointer; and establishing an association between the device number and the structure pointer under an identifier management mechanism.

[0010] In this implementation, the common driver generates a structure for the IPMB controller's register group (i.e., the IPMB interface) and associates the structure pointer with the kernel identifier management mechanism (IDR mechanism). In this way, when the common driver is responsible for communication between the software layer and the hardware layer, it can quickly find the corresponding structure pointer under the IDR mechanism based on the device number of the target device, thereby improving communication efficiency.

[0011] In some possible implementations, the first access message includes the device number of the target device. The extended driver requests a structure pointer to the target device from the public driver, including: passing the device number to the public driver via the extended driver; and querying the structure pointer corresponding to the device number using the identifier management mechanism of the public driver. The identifier management mechanism manages the association between device numbers and structure pointers of hardware devices, and the target device is one of the hardware devices.

[0012] In this way, when the extended driver passes the first access message to the server hardware layer, it can request the structure pointer corresponding to the target device from the common driver. It is no longer necessary to maintain a separate data structure (i.e., structure) transmission method for each extended driver, which helps to reduce the difficulty of driver maintenance.

[0013] In some possible implementations, the second access message includes the device number of the target device. The structure pointer of the target device is obtained through the common driver, including: querying the identifier management mechanism based on the device number through the common driver to obtain the structure pointer corresponding to the device number. The identifier management mechanism is used to manage the association between the device number and the structure pointer of the hardware device. The target device is one of the hardware devices.

[0014] In this way, when the public driver passes messages to its own business software, it can directly obtain the structure pointer based on the IDR mechanism, which is highly efficient.

[0015] In some possible implementations, the method further includes: creating a first character device file for the target device through an extension driver; creating a first access interface for the first business software through the extension driver; and receiving a first access message from the first business software to the target device through the extension driver, including: writing the first access message to the first character file device through the first access interface in the extension driver.

[0016] In this implementation, the extension driver provides an access interface for its respective business software, ensuring that communication between the business software and the hardware layer is achieved.

[0017] In some possible implementations, after using the function to pass the first access message to the target device, the method includes: calling a function that responds to the target device via a public driver to receive the target device's response message to the first business software; writing the response message to a first character device file via an extended driver; and notifying the first business software via the extended driver so that the first business software calls the first access interface to read the response message from the first character device file.

[0018] In this way, the extended driver can pass the response message from the target device (from the hardware to which the target device is connected) to the first business software through the functions provided by the public driver.

[0019] In some possible implementations, the method further includes: creating a second character device file for the target device through a common driver; creating a second access interface for the second business software through a common driver; and obtaining the second access message of the second business software to the target device through the common driver, including: writing the second access message to the second character file device through the second access interface in the common driver.

[0020] In this implementation, the common driver also provides an access interface for its own business software, ensuring that the business software can communicate with the hardware layer.

[0021] In some possible implementations, after using this function to pass the second access message to the target device, the method includes: calling a function of the target device via a common driver to receive the response message from the target device to the second business software; writing the response message to the second character device file via the common driver; and notifying the second business software via the common driver to enable the second business software to call the second access interface to read the response message from the second character device file.

[0022] In this way, the common driver can directly call the corresponding function from the kernel to pass the response message from the target device (from the hardware to which the target device is connected) to the second business software.

[0023] Secondly, embodiments of this application provide a communication device, comprising: a receiving module, configured to receive a first access message from a first service software to a target device via an extended driver, wherein the extended driver is a driver program for implementing communication between the first service software and the target device, and the first service software runs on a Baseboard Management Controller (BMC); and a processing module, configured to request a structure pointer of the target device from a common driver via the extended driver, wherein the common driver is a driver program for implementing communication between a second service software and the target device, the structure pointer being associated with address information of the target device, and the second service software being able to run on the BMC; the processing module is further configured to derive a function required for accessing the target device from the common driver via the extended driver, and, via the extended driver, use the function to transmit the first access message to the target device according to the address information associated with the structure pointer.

[0024] In some possible implementations, the receiving module is further configured to receive a second access message from the second business software to the target device via a common driver; the processing module is further configured to obtain a structure pointer of the target device via a common driver; the processing module is further configured to call the function required to access the target device via a common driver; and the processing module is further configured to use the function to pass the second access message to the target device via a common driver based on the address information associated with the structure pointer.

[0025] In some possible implementations, the processing module is also used to: allocate a device number to the target device through a public driver; define a device structure for the target device, which includes a structure pointer; and establish an association between the device number and the structure pointer under the identifier management mechanism.

[0026] In some possible implementations, the first access message includes the device number of the target device. The processing module is specifically used to: pass the device number to the common driver via the extended driver; and, through the common driver, query the structure pointer corresponding to the device number using the identifier management mechanism. The identifier management mechanism manages the association between the device number and the structure pointer of a hardware device, and the target device is one of the hardware devices.

[0027] In some possible implementations, the second access message includes the device number of the target device. The processing module is specifically used to: query the identifier management mechanism based on the device number through the public driver to obtain the structure pointer corresponding to the device number. The identifier management mechanism is used to manage the association between the device number and the structure pointer of the hardware device. The target device is one of the hardware devices.

[0028] In some possible implementations, the processing module is also used to: create a first character device file for the target device through the extension driver; create a first access interface for the first business software through the extension driver; and the receiving module is specifically used to: write the first access message to the first character file device through the first access interface in the extension driver.

[0029] In some possible implementations, the receiving module is further configured to: call a function of the target device via a common driver to receive a response message from the target device to the first business software; the processing module is further configured to: write the response message to a first character device file via an extended driver; and notify the first business software via the extended driver so that the first business software calls a first access interface to read the response message from the first character device file.

[0030] In some possible implementations, the processing module is also used to: create a second character device file for the target device through a common driver; create a second access interface for the second business software through a common driver; and the receiving module is specifically used to: write the second access message to the second character file device through the second access interface in the common driver.

[0031] In some possible implementations, the receiving module is also used to: call a function of the target device via a common driver to receive the response message from the target device to the second business software; the processing module is also used to: write the response message to the second character device file via a common driver; and notify the second business software via a common driver so that the second business software calls the second access interface to read the response message from the second character device file.

[0032] Thirdly, embodiments of this application provide a server including at least one baseboard management controller (BMC). The BMC includes: at least one memory for storing a program; and at least one processor for executing the program stored in the memory. When the program stored in the memory is executed, the processor is used to execute the method described in the first aspect or any possible implementation of the first aspect.

[0033] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when run on a processor, causes the processor to perform the method described in the first aspect or any possible implementation thereof.

[0034] Fifthly, embodiments of this application provide a computer program product, characterized in that, when the computer program product is run on a processor, it causes the processor to execute the method described in the first aspect or any possible implementation of the first aspect.

[0035] In a sixth aspect, embodiments of this application provide a chip, characterized in that it includes at least one processor and an interface; the at least one processor obtains program instructions or data through the interface; the at least one processor is used to execute program line instructions to implement the method described in the first aspect or any possible implementation of the first aspect.

[0036] It is understood that the beneficial effects of the second to sixth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0037] Figure 1 This is a schematic diagram of a server architecture provided in an embodiment of this application;

[0038] Figure 2 This is a schematic diagram of the architecture of a common driver provided for BMC business software in a specific embodiment of this application;

[0039] Figure 3 This is a schematic diagram illustrating communication between the application layer and the hardware layer through a common driver in a specific embodiment of this application;

[0040] Figure 4 This is a schematic diagram of the architecture of the extended driver provided for BMC business software in a specific embodiment of this application;

[0041] Figure 5 This is a schematic diagram illustrating communication between the application layer and the hardware layer through an extended driver in a specific embodiment of this application;

[0042] Figure 6This is a flowchart illustrating a communication method provided in an embodiment of this application;

[0043] Figure 7 This is a flowchart illustrating a communication method in a specific embodiment of this application;

[0044] Figure 8 This is a flowchart illustrating a communication method in a specific embodiment of this application;

[0045] Figure 9 This is a flowchart illustrating a communication method in a specific embodiment of this application;

[0046] Figure 10 This is a flowchart illustrating a communication method in a specific embodiment of this application;

[0047] Figure 11 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application;

[0048] Figure 12 This is a schematic diagram of the structure of a chip provided in an embodiment of this application. Detailed Implementation

[0049] In this article, the term "and / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The symbol " / " in this article indicates that the related objects are in an "or" relationship; for example, A / B means A or B.

[0050] The terms "first" and "second," etc., used in the specification and claims herein are used to distinguish different objects, not to describe a specific order of objects.

[0051] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0052] In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more, for example, multiple processing units means two or more processing units, multiple elements means two or more elements, etc.

[0053] To facilitate understanding of the technical solutions in this application, the technical terms used in this document are explained below.

[0054] The baseboard management controller (BMC) can perform a series of monitoring and control functions on computer hardware, such as monitoring system temperature and voltage, monitoring the status of fans, power supplies, etc., and making corresponding adjustments. It can also issue alarms and log events when certain parameters exceed their preset thresholds.

[0055] The Intelligent Platform Management Bus (IPMB) is an I2C-based serial bus. The IPMB bus connects various management controllers (including BMCs and various peripheral organization management controllers (SMCs)) to achieve standardized interconnection between different boards. This allows the BMC chip to access the SMCs on the module fan backplane, power supply backplane, etc., through the IPMB interface to manage key parameters such as temperature, voltage, and fan speed of various backplanes.

[0056] Identifier management mechanism (ID Radix, IDR) is a mechanism that associates integer ID numbers with specific data structures (i.e., pointers). It uses a radix tree structure to construct a sparse array, finds the corresponding array element by ID index, and then finds the corresponding data structure pointer.

[0057] A software stack is a collection of independent components that work together to ensure the proper functioning of software. These related components may include the operating system, architecture layer, protocols, runtime environment, database system, and function calls, organized in an architecture where one component is on top of another, like a stack. Generally, the lower-level components in this structure interact directly with the hardware, while the higher-level components perform tasks or provide services to the end user.

[0058] In scenarios where different business software runs on the server for hardware monitoring, if a separate IPMB driver is maintained to adapt to the software stack of each business software, the BMC business software and the underlying IPMB driver will be highly coupled. Developers will need to be familiar with the implementation architecture of each IPMB driver in order to evolve the IPMB driver independently, which is not conducive to maintenance.

[0059] To reduce the maintenance cost of the IPMB driver, this application provides a communication method. This method primarily provides a common driver between the BMC chip and its IPMB controller, and provides separate extended drivers for each BMC service software on the BMC chip. The extended drivers only need to utilize the functions provided by the common driver to implement communication between the application layer and the hardware device using data structures, thereby reducing the overall driver architecture maintenance cost.

[0060] To facilitate understanding of the technical solution of this application, a server provided in the embodiments of this application will be described below.

[0061] For example, Figure 1 The diagram shown is a schematic representation of a server architecture provided in an embodiment of this application. Figure 1 As shown, server 10 is a device that provides computing services. Server 10 includes hardware resources 110, which may include, but are not limited to, hardware such as processors, memory, hard disks, system buses, fans, and power supplies. It should be understood that these hardware resources 110 may be formed by the hardware of one or more server nodes.

[0062] Server 10 also includes a baseboard management controller (BMC) 120, which is an independent system-on-a-chip (SoC) embedded in server 10. At the hardware level, BMC 120 may include various components such as a BMC processor, memory, storage, and peripheral I / O. Figure 1 (Not explicitly stated), but not limited to these. For example, such as... Figure 1 As shown, the BMC120 may specifically include an IPMB controller 121, which can be used to manage the IPMB bus. The controller 121 can connect to the hardware resources 110 of the server 10 through the IPMB bus, so that the BMC120 can communicate with the hardware resources 110 of the server 10 through the IPMB physical channel.

[0063] In this example, controller 121 can provide multiple IPMB interfaces to connect to a hardware in hardware resource 110. Each IPMB interface can be implemented through a register group. Different register groups can be used to store communication information with different hardware. For example, register group 1 stores information sent by BMC 120 to server memory, or stores information sent by server memory to BMC 120, and so on.

[0064] Furthermore, in this embodiment, at the software level, the BMC120 can run embedded operating system firmware built on the Linux kernel, specifically including the BMC hardware bootloader, kernel 130, and drivers ( Figure 1 The document only shows the IPMB driver architecture, but is not limited to it), file system, IPMI application, web services and other software stacks, which are responsible for providing various interfaces and services required by the BMC system, realizing centralized operation management and monitoring of server 10, fault early warning / alarm, configuration deployment and other operation and maintenance management functions, and ensuring the safe and reliable operation of server 10.

[0065] For example, multiple business software programs (i.e., BMC management software systems) A, B, ... can be deployed on BMC120. Each business software program A, B, ... can communicate with controller 121 through its corresponding IPMB driver when running independently, thereby monitoring hardware resources 110. It is understood that the multiple business software programs can run in different containers, and these containers run on the aforementioned embedded operating system firmware. For example, business software A can be a business software program in the I BMC system, and business software B can be a business software program in the OPN BMC system.

[0066] In this embodiment, the IPMB driver architecture deployed between business software A, B, ... and controller 121 includes at least one common driver a, which can serve as the IPMB driver for one of the BMC business software (business software A is taken as an example in this document).

[0067] In this embodiment, BMC120 can assign globally unique device numbers (bus_id) to each register group (or IPMB interface) of controller 121 through common driver a. Furthermore, server 10 can map each register address (e.g., base address and offset address) of the register group to the virtual memory space through common driver a, obtaining the corresponding virtual memory address. Then, for each register group, its virtual memory address and other related information (e.g., semaphores) are encapsulated into a device structure. This information encapsulated in the device structure can be described by pointers. Thus, each device structure can be considered a hardware device to be accessed by the business software. Next, common driver a associates the pointer of each device structure with its corresponding device number to the IDR mechanism of kernel 130 (e.g., Linux kernel 1). Each device number can be represented as an integer under the IDR mechanism. In this way, multiple device structures associated with their corresponding device numbers form a device tree under the IDR mechanism, facilitating the rapid retrieval of a specific device structure.

[0068] In this embodiment, BMC120, through the common driver a, can also create IPMB character device files corresponding to each IPMB interface of controller 121 for access by service software A. For ease of description, the IPMB character device file created through the common driver a can be referred to as the second character device file. It should be understood that each second character device file can correspond to one IPMB interface. As a specific example, the filename of the second character device file under the device directory / dev can be named "ipmb-x", where x = 0, 1, 2, ...

[0069] Furthermore, the public driver 'a' can also be used to register file operation interfaces for business software A to perform operations on the second character device file ipmb-x, thereby passing hardware access messages from business software A to the second character device file or reading hardware response messages from the second character device file. For example, as shown... Figure 2 As shown, the file operation interface may include, but is not limited to, write, read, poll, and i0ctl. For example, the i0ctl interface can define different custom command interfaces, such as... Figure 2 The cmd1, cmd2, ... etc. shown are used to customize the interface when the corresponding business software needs to communicate through the command interface, thereby improving system availability.

[0070] In addition, the common driver 'a' can also be used to implement functions that access hardware resources 110 (including but not limited to...) Figure 2 The IPMB message generation and reception functions shown are imported into the kernel 130 space using the EXPORT_SYMBOL macro to be shared throughout the IPMB driver architecture. It should be understood that functions or symbols defined by the EXPORT_SYMBOL macro are exposed to the kernel code and can be directly called in other kernel modules without modifying the kernel code. In other words, using EXPORT_SYMBOL allows a function to be exported as a symbol for use by other modules.

[0071] The following example illustrates the communication principle of common driver 'a', using the example of business software sending access messages to certain hardware. Please refer to [link / reference]. Figure 3 As shown, BMC120 obtains device structures 30a, 30b, ... describing each register group of controller 121 through address mapping and information encapsulation in steps 1 and 2, and executes step 3 through common driver a to associate pointers of these device structures with the IDR mechanism of kernel 130.

[0072] In this example, if business software A needs to communicate with a hardware Dev (e.g., an embedded microcontroller (management engine, ME) in a PCH chipset of server 10), the communication between business software A and the hardware Dev is transmitted through the IPMB interface 0 of controller 121 (this IPMB interface 0 is implemented through register group 0, which corresponds to device structure 30a). Business software A can send an access message ipmb_msg to the common driver a. Specifically, business software A calls the write interface in the common driver a through step 5, and then executes step 6 to perform a write operation in the character device file Dev / ipmb-0 created corresponding to the current IPMB interface 0, passing the access message ipmb_msg into the character device file Dev / ipmb-0 byte by byte. Through steps 7 and 8, based on the device number contained in the access message ipmb_msg, the pointer to the device structure 30a associated with the device number is quickly obtained from the device tree of the IDR mechanism. Next, the common driver a executes step 9, and according to the register address and other information pointed to by the pointer, calls the IPMB message sending function to pass the access message written in the character device file Dev / ipmb-0 to register group 0 of the controller 121 (which may be the transmit buffer register in register group 0), and then passes it to the hardware Dev to manage the relevant parameters of the hardware Dev.

[0073] Similarly, if the common driver 'a' receives a response message from the hardware Dev to the business software A, it will trigger an interrupt from the common driver 'a' to call the IPMB message receiving function. Then, it will transfer the response message from register group 0 of the controller 121 to the character device file Dev / ipmb-0, notifying the business software A to call the read interface to perform a read operation on the character device file Dev / ipmb-0 to obtain the response message. It is understandable that when the business software A sends or receives other commands or information from the controller 121 through the common driver 'a', the principle is similar to the message sending and receiving process described above, and will not be elaborated further.

[0074] At this point, the common driver 'a' can serve as the IPMB driver for business software 'A', efficiently enabling communication between the application layer and the hardware layer based on the kernel IDR mechanism.

[0075] In this embodiment, refer again Figure 1 As shown, the BMC120 in server 10 may switch from running business software A to running other different business software B, C, ... The IPMB driver architecture of server 10 also provides extended drivers b, c, ... for business software B, C, ... respectively. The working principle is explained below using one of the extended drivers b as an example. The working principle of the other extended drivers is similar to that of extended driver b.

[0076] The extended driver b can be used to create corresponding character device nodes (also referred to as "first character device nodes" in this document) for the IPMB interface provided by controller 121. For the same IPMB interface, the naming convention for the first character device file is different from that for the second character device file. For example, the filename of the first character device file under the device directory / dev can be named "ipmbx", where x = 0, 1, 2, ...

[0077] The extended driver b can also be used to register file operation interfaces for business software B to perform operations on the first character device file ipmbx. For an example, please refer to [link / reference]. Figure 4 As shown, the file operation interface may include an i0ctl operation interface that can pass multiple commands, such as read cmd, write cmd, set cmd, get cmd, etc., but is not limited to these.

[0078] Furthermore, in this embodiment, when the application layer communicates with the hardware resource 110 through the extended driver b, the common driver a is also used to provide the device structure and functions required by the extended driver b based on the IDR mechanism, so as to assist the extended driver b in realizing the communication between the corresponding business software B and the hardware resource 110.

[0079] The following example illustrates the communication principle of extended driver b by showing how business software sends access commands to certain hardware. Please refer to [link / reference]. Figure 5 As shown, BMC120 obtains device structures 30a, 30b, ... describing each register group of controller 121 through address mapping and information encapsulation in steps 1 and 2, and executes step 3 through common driver a to associate pointers of these device structures with the IDR mechanism of kernel 130.

[0080] In this example, such as Figure 5 As shown, if business software B needs to communicate with a certain hardware Dev, and the communication between business software A and the hardware Dev is transmitted through the IPMB interface 0 of controller 121 (this IPMB interface 0 is implemented through register group 0, and register group 0 corresponds to device structure 30a), then business software B can send an access message cmd arg to the extended driver b. Specifically, business software B calls the ioctl operation interface in the extended driver b in step 5, and performs a write operation in the character device file Dev / ipmb0 created by the corresponding IPMB interface 0 in step 6 using the write cmd command method, writing the access message cmdarg into the character device file Dev / ipmb0 byte by byte, and then executes step 7, requesting to obtain the device structure from the common driver a according to the device number contained in the access message cmdarg.

[0081] Next, the common driver a quickly obtains the pointer to the device structure 30a associated with the current device number from the device tree of the IDR mechanism and provides it to the extended driver b through step 8. Then, the extended driver b executes step 9, requesting the common driver a to call the IPMB message sending function. The extended driver b can declare this function using the `extern` keyword, thus gaining the ability to use it. Then, the extended driver b executes step 10, using the function to pass the access message `cmd arg` written in the character device file Dev / ipmb0 to register group 0 (which could be the transmit buffer register in register group 0) as described by the pointer, based on the register address information pointed to by the pointer, and thus it is obtained by the hardware Dev. It should be understood that the main function of the `extern` keyword is to declare that a variable or function is defined in another file, allowing variables or functions to be shared between different files.

[0082] Similarly, if common driver a receives a response message from hardware Dev to business software b, it will trigger an interrupt to call the IPMB message receiving function. The response message will then be transferred from register group 0 of controller 121 to the character device file Dev / ipmb0 of extended driver b. Extended driver b will then instruct business software B to perform a read operation on the character device file Dev / ipmb0 using the read cmd command to obtain the response message. It is understandable that when business software B sends or receives other commands or information from controller 121 through extended driver b, and when other business software exchanges commands / messages with controller 121 through its own extended driver, the principle is similar to the message sending and receiving process implemented based on extended driver b described above, and will not be repeated here.

[0083] Thus, in this embodiment, based on the common driver 'a', access interfaces required by various business software are created through extended drivers. These access interfaces only need to reuse the hardware resource access functions (including providing relevant functions and corresponding device structures) in the common driver 'a' to achieve communication between the business software and hardware resources. In other words, different business software share a single IPMB driver architecture. The common driver 'a' achieves standardized deployment of IPMB drivers required by different business software, eliminating the need to provide differentiated implementations of functions and data structures for the IPMB drivers of different business software. This reduces maintenance difficulty and thus lowers IPMB driver maintenance costs. Furthermore, when switching BMC business software during server system operation, there is no need to reload a new IPMB driver, facilitating maintenance.

[0084] Next, based on the content described above, a communication method provided by an embodiment of this application will be introduced. It is understood that this method is proposed based on the content described above, and some or all of the content of this method can be found in the description above.

[0085] Please see Figure 6 , Figure 6 This is a flowchart illustrating a communication method provided in an embodiment of this application. It is understood that this method can be executed by any device, equipment, platform, or device cluster with computing and processing capabilities. The following description uses... Figure 1 The example shown is executed on the BMC of server 10. Figure 6 As shown, the method may include:

[0086] In S610, the first access message from the first service software to the target device is received through the extended driver.

[0087] In this embodiment, combined again Figure 1 As shown, the service software B running on BMC120 (also referred to herein as the first service software for ease of description) can communicate with different IPMB interfaces of controller 121 through the IPMB driver. By writing access messages to the register group on controller 121 that implements the IPMB interface, the access message can be passed to the hardware resource 110 connected to the register group. For example, the extended driver b can serve as the IPMB driver in the IPMB driver architecture of BMC120 for implementing communication between service software B and controller 121.

[0088] For example, when business software B needs to access a certain IPMB interface, or register group, of controller 121, i.e., the target device, a first access message is generated and passed to the extended driver b. The first access message may contain the target device's device number (bus_id) on the IPMB bus, the message body content, and the message format, but is not limited to these.

[0089] S620 requests the structure pointer of the target device from the common driver through the extended driver.

[0090] In this embodiment, the IPMB driver architecture of BMC120 also provides an IPMB driver for the running business software A (also referred to herein as "second business software", the same below) to enable communication between business software A and controller 121, namely common driver a. The common driver a is also used to provide the required function and data structure for each extended driver b, c, ... in the IPMB driver architecture.

[0091] For example, after the public driver 'a' is loaded by BMC120, it can define corresponding device structures for the register groups of controller 121. Each device structure pointer (i.e., a structure pointer) can be used to describe the corresponding register address information. Then, the public driver 'a' can associate each device structure pointer of controller 121 with its device number to the IDR mechanism of kernel 130. It can be understood that the device number can be represented by an integer under the IDR mechanism. In this way, when the public driver 'a' obtains the device number of any target device, it can quickly query the corresponding structure pointer from the IDR mechanism.

[0092] Therefore, after the extended driver receives the first access message, it can pass the device number in the first access message to the common driver a, so that the common driver a can look up the structure pointer corresponding to the target device under the IDR mechanism.

[0093] S630, through extended drivers, exports the functions required to access the target device from the common driver.

[0094] In this embodiment, the extended driver b directly requests the functions required to access the target device (such as the IPMB message sending function required to pass the access message) from the common driver a. In this way, the kernel 130 does not need to provide a set of functions specifically for the extended driver b, which helps to reduce the difficulty of driver maintenance.

[0095] S640, through extended driver, uses this function to pass the first access message to the target device based on the address information associated with the structure pointer.

[0096] In this embodiment, the extended driver b uses a function derived from the common driver a to pass the first access message to the target device pointed to by the address information associated with the structure pointer, thereby completing the message transmission from the business software B to the target device.

[0097] It should be understood that other extended drivers c, d, ... can also obtain the required function and structure pointers through the common driver a when passing access messages of their respective business software C, D, ... The principle is similar to the working principle of extended driver b mentioned above, and will not be repeated here.

[0098] In this way, the IPMB driver required by different business software can be uniformly deployed through the common driver 'a'. In other words, the IPMB driver architecture only needs one common driver 'a' to uniformly provide the required functions and data structures for the extended drivers of each business software. Each extended driver only needs to provide an access interface for its own business software to obtain access messages, which greatly reduces the maintenance difficulty of the IPMB driver and thus helps to reduce maintenance costs.

[0099] The following is a detailed explanation of the communication principle between BMC service software and hardware resource 110 through a specific implementation.

[0100] For example, Figure 7 A flowchart illustrating a specific embodiment of the communication method provided in this application is shown. Figure 7 As shown, the method may specifically include:

[0101] S701 assigns a device number to the target device through a common driver;

[0102] S702 defines the device structure of the target device.

[0103] In this embodiment, the target device is the register group of the controller 121 that the BMC service software needs to access.

[0104] For example, after the BMC120 loads the common driver a, it can assign a globally unique device number to the register group (including the target device) under each IPMB interface of the controller 121 through the common driver a, and define the device structure of each register group. It should be understood that each device structure of the controller 121 may include multiple variables, such as a structure pointer and the device number of the register group, but not limited to this. The structure pointer is associated with the register address information of the corresponding register group.

[0105] S703 establishes an association between the device number and the structure pointer under the identifier management mechanism.

[0106] In this embodiment, the common driver 'a' can establish a mapping relationship between the device numbers of each register group of the controller 121 and their structure pointers under the IDR mechanism of the kernel 130. The device number can be represented by an integer under the IDR mechanism. In this way, the common driver 'a' can quickly obtain the corresponding structure pointer by querying under the IDR mechanism based on any device number.

[0107] Furthermore, for example, the public driver a can also be used to implement functionalities for accessing hardware resources 110 (including but not limited to...) Figure 2 The IPMB message generation and reception functions shown are imported into the kernel 130 space using the EXPORT_SYMBOL macro to be shared throughout the IPMB driver architecture. It should be understood that functions or symbols defined by the EXPORT_SYMBOL macro are exposed to the kernel code and can be directly called in other kernel modules without modifying the kernel code. In other words, using EXPORT_SYMBOL allows a function to be exported as a symbol for use by other modules.

[0108] S704, create a second character device file for the target device through a common driver.

[0109] In this embodiment, the common driver a also creates a corresponding virtual device file for the IPMB interface provided by the controller 121, so that the business software A can access it.

[0110] For example, the virtual device file created by the common driver 'a' for the IPMB interface of controller 121 can be a character device file, which is referred to as the second character device file for ease of description. As a specific example, each second character device file can be named "ipmb-x" in the device directory / dev, where x = 0, 1, 2, ... For example, the second character device file created for IPMB interface 0 (i.e., register group 0) is named "ipmb-0", the second character device file created for IPMB interface 1 (i.e., register group 1) is named "ipmb-1", and so on.

[0111] S705 creates a second access interface for the second business software through a common driver.

[0112] In this embodiment, the common driver a serves as the IPMB driver for the business software A, and also creates an access interface (i.e., a second access interface) for the software so that the business software A can call these access interfaces to perform corresponding operations on the second character device file and realize communication with the controller 121.

[0113] For example, the second access interface created by the public driver 'a' may include file operation interfaces such as write, read, poll, and ioctl, but is not limited to these. It should be understood that the write interface can be used to perform write operations on the second character device file, the read interface can be used to perform read operations on the second character device file, the poll interface can be used to perform polling operations, and ioctl can be used to execute various custom commands.

[0114] S706 obtains the second access message from the second business software to the target device through the common driver.

[0115] In this embodiment, when business software A needs to access the register group of a controller 121 (i.e., the target device), it transmits an access message to the common driver a. For ease of description, this access message is also referred to herein as a second access message. The second access message may include, but is not limited to, the device number (bus_id) of the target device, the main content of the message, and the message format.

[0116] Specifically, executing S706 may include:

[0117] In the S7061 common driver, the second access message is written to the second character file device corresponding to the target device through the second access interface.

[0118] In this embodiment, target software A can call the writ interface in the public driver to write the second access message byte by byte into the second character device file corresponding to the target device. In this way, public driver A can obtain the second access message.

[0119] Next, the public driver 'a' parses the second access message to obtain various parameters and information contained therein, including but not limited to the device number of the target device, as well as the message body content and message format, etc.

[0120] S707 obtains the structure pointer of the target device through the common driver.

[0121] In this embodiment, the common driver a obtains the pointer to the device structure corresponding to the device number of the target device by indexing under the IDR mechanism of kernel 130, thereby obtaining various information such as the target device address encapsulated in the device structure.

[0122] S708 calls the functions required to access the target device through a common driver.

[0123] In this embodiment, the common driver a also calls the function required to access the target device from the kernel 130, such as the IPMB message sending function.

[0124] S709, through a common driver, uses this function to pass the second access message to the target device based on the address information associated with the structure pointer.

[0125] In this embodiment, the common driver 'a' uses the IPMB message sending function to write the second access message (mainly the message body content) into the target device based on parameters such as the register address pointed to by the device structure pointer. This completes the message transmission from service software A to the target device, after which the hardware resource 110 connected to the target device can retrieve the message from the target device.

[0126] For example, if the hardware resource 110 connected to the target device responds to the access of the business software A and sends a response message to the common driver a, then as follows Figure 8 As shown, the communication method also includes:

[0127] The S710, through a common driver, calls the function of the target device to receive the target device's response message to the second business software.

[0128] In this example, when the target device (e.g., the receive buffer register in the target device) receives the response message from the hardware resource 110 it is connected to, the target device sends the response message to the business software A. At this time, an interrupt is triggered in the common driver a, and the common driver a calls the IPMB message receiving function to receive the response message.

[0129] The S711 writes response messages to a second character device file via a common driver.

[0130] In this example, the public driver 'a' can use the IPMB message receiving function to write the response message to the second character device file corresponding to the target device.

[0131] S712 notifies the second service software through the common driver, so that the second service software calls the second access interface to read the response message from the second character device file.

[0132] In this example, after the public driver 'a' writes the response message to the second character device file, it notifies the business software 'A' that it has received a response message. This allows the business software 'A' to call the read interface in the public driver 'a' to perform a read operation on the second character device file, thereby retrieving the response message. This completes the communication between the hardware and the business software 'A'.

[0133] In this way, the common driver a provides the access interface and functions required by the business software A, as well as the data structure (i.e., structure pointer) for communicating with the hardware. Moreover, this data structure can be obtained quickly based on the IDR mechanism, resulting in high communication efficiency.

[0134] Next, in conjunction with the appendix Figure 9 This section introduces the principle of BMC business software communicating with hardware based on extended drivers. This example uses extended driver b as an example; it should be understood that the working principle of other extended drivers is similar. Please refer to [link / reference]. Figure 9 As shown, the communication method may further include:

[0135] S901 creates a first character device file for the target device through an extended driver.

[0136] In this embodiment, after the extended driver b is loaded by BMC120, a corresponding virtual device file can be created for the IPMB interface provided by controller 121, so that the business software B can access it.

[0137] For example, the virtual device file created by the extended driver b for the IPMB interface can be a character device file, which, for ease of description, is referred to as the first character device file. As a specific example, the filename of the first character device file in the device directory / dev differs from that of the second character device file created for the same IPMB interface. For instance, the first character device file in the device directory / dev could be named "ipmbx", where x = 0, 1, 2, ..., but is not limited to this. For example, the first character device file created for IPMB interface 0 (i.e., register group 0) is named "ipmb0", and the first character device file created for IPMB interface 1 (i.e., register group 1) is named "ipmb1", and so on.

[0138] S902 creates a first access interface for the first business software through an extended driver.

[0139] In this embodiment, the extended driver b, acting as the IPMB driver for the business software B, also creates access interfaces (i.e., first access interfaces) for the business software B. This allows the business software B to call these first access interfaces to perform corresponding operations on the first character device file, thereby enabling communication with the controller 121. For example, the first access interface created by the extended driver b can be an ioctl file operation interface to transmit read cmd, write cmd, set cmd, get cmd, and other custom commands, but is not limited to these.

[0140] S903, through extended driver, receives the first access message from the first service software to the target device.

[0141] In this embodiment, when business software B accesses a register group (i.e., the target device) of controller 121, business software B transmits the corresponding first access message to its own driver, i.e., extended driver b. This first access message may include, but is not limited to, the device number (bus_id) of the target device, the message body content, and the message format.

[0142] Specifically, executing S903 may include:

[0143] S9031, in the extended driver, writes the first access message to the first character file device through the first access interface.

[0144] In this embodiment, business software B can call the ioctl interface in extended driver b to execute the write command, writing the first access message byte by byte into the first character device file corresponding to the target device. In this way, extended driver b can receive the first access message. Next, extended driver b parses the access message to obtain various parameters and information contained within it, including but not limited to the device number of the target device, the message body content, and the message format, etc.

[0145] S904 requests the structure pointer of the target device from the common driver through the extended driver.

[0146] In this embodiment, the extended driver b can obtain the resources (i.e., device structures) of each IPMB device from the IDR mechanism through the common driver a.

[0147] Specifically, executing S904 may include:

[0148] S9041 passes the device number to the common driver through the extended driver.

[0149] In this example, after extended driver b parses the various parameters and information from the first access message via S9031, extended driver b converts the message format of these parameters and information into the message format required by common driver a, so that these parameters and information can be executed by common driver a and the functions provided by common driver a. Furthermore, extended driver b adds information describing the message length to the first access message to ensure the integrity of the access message during information exchange between extended driver b and common driver a.

[0150] Next, the extended driver b transmits the device number of the target device (in the message format required by the common driver a) after the message format has been converted to the common driver a, in order to request the common driver a to provide the device structure corresponding to the target device.

[0151] S9042, through the public driver, queries the structure pointer corresponding to the device number under the identifier management mechanism.

[0152] In this example, common driver a, based on the device number provided by extended driver b, queries the device structure pointer associated with the device number of the target device from the association between device numbers and structure pointers of hardware devices (register groups) managed by the IDR mechanism of kernel 130, and provides it to extended driver b, which then obtains the target structure.

[0153] S905, through extended drivers, exports the functions required to access the target device from the common driver.

[0154] In this embodiment, in addition to obtaining the structure pointer of the target device through the common driver a, the extended driver b can also obtain the functions required to access the target device from the kernel 130 space through the common driver a, such as the IPMB message sending function, but is not limited to this.

[0155] For example, the IPMB message sending function exported by extended driver b from public driver a can be declared using the `extern` keyword, thus enabling the use of this function. Furthermore, extended driver b has converted the parameters and information of the first access message into the format required by public driver a; that is, the first access message after format conversion is in a format that the IPMB message sending function can execute. Therefore, extended driver b can use this IPMB message sending function to transmit the first access message.

[0156] S906, through the extended driver, uses this function to pass the first access message to the target device based on the address information associated with the structure pointer.

[0157] In this embodiment, the extended driver b, based on the address information pointed to by the target structure pointer, uses the IPMB message sending function to write the first access message (mainly the message content after being converted into the message format required by the common driver a) to the target device. This completes the message transmission from the service software B to the target device, after which the hardware resource 110 connected to the target device can retrieve the message from the target device.

[0158] For example, if the hardware resource 110 connected to the target device responds to the access of the business software B and sends a response message to the common driver a, then as follows Figure 10 As shown, the communication method also includes:

[0159] S907, through a common driver, calls the function of the target device to receive the response message from the target device to the first business software.

[0160] In this example, when the target device receives a response message from the hardware resource 110 it is connected to, the target device sends the response message to the business software A. At this time, an interrupt is triggered in the common driver a. The common driver a calls the function that responds to the target device, namely the IPMB message receiving function, and provides it to the extended driver b for receiving the response message.

[0161] The S908 writes response messages to the first character device file via an extended driver.

[0162] In this example, the extended driver b can use the extern keyword to declare the IPMB message receiving function, thereby using the function to write the response message to the first character device file corresponding to the target device.

[0163] S909 notifies the first service software through the extended driver, so that the first service software calls the first access interface to read the response message from the first character device file.

[0164] In this example, after the extended driver b writes the response message to the first character device file of the target device, it notifies the business software B that it has received the response message. The business software B will then call the ioctl interface to execute the read command, perform a read operation on the first character device file, and thus obtain the response message.

[0165] Thus, in this embodiment, the common driver a uniformly provides the functions and data structures (i.e., structure pointers) required for communication between the different business software B, C, ... and the hardware for each extended driver b, c, ... . The extended drivers b, c, ... only need to provide access for their respective business software B, C, ... , which greatly reduces the maintenance cost of the IPMB driver on the server. Furthermore, during the operation of the server system, if the BMC business software is switched to manage hardware resources 110, there is no need to reload a new IPMB driver, which facilitates maintenance.

[0166] Based on the methods described in the above embodiments, this application provides a communication device. Please refer to... Figure 11 , Figure 11 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application.

[0167] like Figure 11 As shown, the device 1100 may include a receiving module 1101 and a processing module 1102. The receiving module 1101 can be used to receive a first access message from a first service software to a target device via an extended driver. The extended driver is a driver program for implementing communication between the first service software and the target device, and the first service software runs on a Baseboard Management Controller (BMC). The processing module 1102 can be used to request a structure pointer of the target device from a common driver via the extended driver. The common driver is a driver program for implementing communication between a second service software and the target device. The structure pointer is associated with the address information of the target device, and the second service software can run on the BMC. Furthermore, the processing module 1102 can also be used to derive the function required to access the target device from the common driver via the extended driver; and, via the extended driver, use the function to transmit the first access message to the target device based on the address information associated with the structure pointer.

[0168] In some possible embodiments, the receiving module 1101 can also be used to receive a second access message from the second service software to the target device via the common driver. The processing module 1102 can also be used to obtain a structure pointer of the target device via the common driver, and to call the function required to access the target device via the common driver. The processing module 1102 can also be used to transmit the second access message to the target device via the common driver, based on the address information associated with the structure pointer, using this function.

[0169] It should be understood that the above-described device is used to execute the methods in the above embodiments. The implementation principle and technical effect of the corresponding program modules in the device are similar to those described in the above methods. The working process of the device can be referred to the corresponding process in the above methods, and will not be repeated here.

[0170] Based on the methods in the above embodiments, this application provides a computer-readable storage medium storing a computer program that, when run on a processor, causes the processor to execute the methods in the above embodiments.

[0171] Based on the methods in the above embodiments, this application provides a computer program product, characterized in that, when the computer program product is run on a processor, the processor executes the methods in the above embodiments.

[0172] Based on the methods described in the above embodiments, this application also provides a chip. Please refer to... Figure 12 , Figure 12 This is a schematic diagram of a chip structure provided in an embodiment of this application. Figure 12 As shown, chip 900 includes one or more processors 901 and interface circuitry 902. Optionally, chip 900 may also include a bus 903. Wherein:

[0173] The processor 901 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed through integrated logic circuits in the hardware of the processor 901 or through software instructions. The processor 901 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods and steps disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor.

[0174] The interface circuit 902 can be used to send or receive data, instructions or information. The processor 901 can use the data, instructions or other information received by the interface circuit 902 to process the data, instructions or other information, and can send the processed information out through the interface circuit 902.

[0175] Optionally, chip 900 also includes memory, which may include read-only memory and random access memory, and provides operation instructions and data to the processor. A portion of the memory may also include non-volatile random access memory (NVRAM).

[0176] Optionally, the memory stores executable software modules or data structures, and the processor can execute corresponding operations by calling the operation instructions stored in the memory (which may be stored in the operating system).

[0177] Optionally, the interface circuit 902 can be used to output the execution results of the processor 901.

[0178] It should be noted that the functions of the processor 901 and the interface circuit 902 can be implemented through hardware design, software design, or a combination of hardware and software; no restrictions are imposed here.

[0179] It should be understood that each step of the above method embodiments can be completed by hardware logic circuits or software instructions in a processor.

[0180] It is understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. In addition, in some possible implementations, each step in the above embodiments may be selectively executed according to the actual situation, and may be partially or fully executed, which is not limited here.

[0181] It is understood that the processor in the embodiments of this application may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0182] The method steps in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can reside in an ASIC.

[0183] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive (SSD)).

[0184] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application.

Claims

1. A communication method, characterized in that, The method includes: The extended driver receives a first access message from the first service software to the target device. The extended driver is a driver program used to enable communication between the first service software and the target device. The first service software runs on the baseboard management controller (BMC). The extended driver requests a structure pointer of the target device from the common driver. The common driver is a driver program used to enable communication between the second business software and the target device. The structure pointer is associated with the address information of the target device. The second business software can run on the BMC. The extended driver derives the functions required to access the target device from the public driver; Through the extended driver, the first access message is transmitted to the target device using the function based on the address information associated with the structure pointer.

2. The method according to claim 1, characterized in that, The method further includes: The second access message of the second business software to the target device is obtained through the public driver; The structure pointer of the target device is obtained through the common driver; The public driver is used to invoke the functions required to access the target device. Using the common driver, and based on the address information associated with the structure pointer, this function transmits the second access message to the target device.

3. The method according to claim 1 or 2, characterized in that, Before receiving the first access message from the first service software to the target device, the method includes: A device number is assigned to the target device through the common driver; Define a device structure for the target device, wherein the device structure includes a structure pointer; The device number and the structure pointer are associated under the identifier management mechanism.

4. The method according to any one of claims 1 or 2, characterized in that, The first access message includes the device number of the target device. The step of requesting a structure pointer of the target device from the public driver through the extended driver includes: The device number is passed from the extended driver to the common driver; Through the public driver, the structure pointer corresponding to the device number is queried under the identifier management mechanism. The identifier management mechanism is used to manage the association between the device number and the structure pointer of the hardware device. The target device belongs to one of the hardware devices.

5. The method according to claim 2, characterized in that, The second access message includes the device number of the target device. The step of obtaining the structure pointer of the target device through the common driver includes: Through the public driver, the device number is queried under the identifier management mechanism to obtain the structure pointer corresponding to the device number. The identifier management mechanism is used to manage the association between the device number and the structure pointer of the hardware device. The target device belongs to one of the hardware devices.

6. The method according to any one of claims 1 or 5, characterized in that, The method further includes: A first character device file is created for the target device using the extended driver. The extended driver creates a first access interface for the first business software. The step of receiving the first access message from the first service software to the target device via the extended driver includes: In the extended driver, the first access message is written to the first character device file through the first access interface.

7. The method according to claim 6, characterized in that, After using the function to pass the first access message to the target device, the method includes: The public driver calls a function that responds to the target device to receive the target device's response message to the first service software. The response message is written to the first character device file via the extended driver; The extended driver notifies the first business software, causing the first business software to call the first access interface to read the response message from the first character device file.

8. The method according to claim 2, characterized in that, The method further includes: A second character device file is created for the target device using the public driver. A second access interface is created for the second business software through the public driver; The step of obtaining the second access message of the second business software to the target device through the public driver includes: In the common driver, the second access message is written to the second character device file through the second access interface.

9. The method according to claim 8, characterized in that, After using the function to pass the second access message to the target device, the method includes: The public driver calls a function that responds to the target device to receive the target device's response message to the second service software. The response message is written to the second character device file via the public driver; The public driver notifies the second business software, causing the second business software to call the second access interface to read the response message from the second character device file.

10. A server, characterized in that, Includes at least one baseboard management controller (BMC), said BMC including: At least one memory for storing programs; At least one processor for executing the program stored in the memory; When the program stored in the memory is executed, the processor is used to execute the method as described in any one of claims 1-9.

Images