Central processing unit driven invocation method, apparatus and device

Abstract

The application provides a central processor driven calling method, device and equipment. The calling method is applied to a first electronic equipment, and the method comprises the following steps: receiving an access request sent by a second electronic equipment; based on the access request, determining a physical machine with driving information in a cluster as a target equipment, and sending the access request to the target equipment; wherein the driving information in the target equipment is used for sending to the second electronic equipment; the cluster comprises a plurality of physical machines, and the central processor architecture supported by at least one physical machine in the plurality of physical machines is different from the central processor architecture supported by each of the remaining physical machines; and the physical machine is deployed with a container comprising driving information corresponding to the central processor architecture supported by the physical machine. Through the above method, the complex process of screening and searching for the driving information to be called in the massive public information is avoided, and the efficiency of calling the driving information by the second electronic equipment is improved.

Description

Technical Field

[0001] This application relates to the field of electronic technology, and in particular to a method, apparatus, and device for central processing unit (CPU)-driven invocation. Background Technology

[0002] Currently, different central processing unit (CPU) architectures correspond to different driver information. In electronic devices, it is necessary to install the driver information corresponding to the CPU architecture so that the CPU in the electronic device can control external devices (such as speakers, printers, etc. connected to the electronic device) based on the driver information.

[0003] Therefore, how electronic devices obtain the necessary driving information is an urgent problem to be solved. Summary of the Invention

[0004] The present application provides a method, apparatus, and device for invoking a central processing unit driver, which are used to enable electronic devices to invoke driver information.

[0005] In a first aspect, this application provides a method for invoking a central processing unit driver, applied to a first electronic device, the method comprising:

[0006] Receive an access request sent by a second electronic device, wherein the access request is used to indicate a request to obtain driver information;

[0007] Based on the access request, the physical machine containing the driver information is identified as the target device among the physical machines in the cluster, and the access request is sent to the target device; wherein, the driver information in the target device is used to send to the second electronic device; the cluster includes multiple physical machines, at least one of the multiple physical machines supports a different central processing unit architecture than the central processing unit architectures supported by the other physical machines; the physical machine deploys a container containing driver information corresponding to the central processing unit architecture supported by the physical machine.

[0008] In some embodiments, the first electronic device has a plurality of first interfaces, wherein physical machines with different driving information correspond to different first interfaces, and physical machines with the same driving information correspond to the same first interface; the access request is specifically used to indicate the driving information of the physical machine corresponding to the first interface.

[0009] Receive access requests sent by a second electronic device, including:

[0010] Based on the first interface, the access request sent by the second electronic device is received;

[0011] Based on the access request, the physical machine containing the driver information is identified as the target device among the physical machines in the cluster, and the access request is sent to the target device, including:

[0012] Based on the first interface, among the physical machines included in the cluster, the physical machine corresponding to the first interface is identified as the target device; and the access request is sent to the target device.

[0013] In some embodiments, the container in the physical machine has tag information, which is used to indicate the central processing unit architecture type corresponding to the driver information stored in the container; the first interface has an interface name;

[0014] Based on the first interface, among the physical machines included in the cluster, the physical machine corresponding to the first interface is identified as the target device, including:

[0015] Based on the first interface, according to the tag information of each container in the cluster, the interface name of the first interface, and the preset correspondence, the physical machine corresponding to the first interface is determined, and the physical machine corresponding to the first interface is determined as the target device. The preset correspondence is used to indicate the correspondence between the interface name of the first interface and the tag information.

[0016] In some embodiments, the first interface corresponds to multiple physical machines;

[0017] Based on the first interface, among the physical machines included in the cluster, the physical machine corresponding to the first interface is identified as the target device, including:

[0018] Based on the first interface, among the physical machines included in the cluster, the physical machine corresponding to the first interface is determined as a candidate device;

[0019] Based on the first interface, the network traffic usage of the candidate devices and the number of access requests currently received by the first interface are obtained. Based on the network traffic usage of the candidate devices and the number of access requests currently received by the first interface, the target device corresponding to the access request is determined among the candidate devices.

[0020] In some embodiments, the first electronic device has a second interface, which is a presentation layer state transition interface; sending the access request to the target device includes:

[0021] Based on the first interface, the address information of the target device and the access request are sent to the second interface in the first electronic device;

[0022] Based on the second interface, the access request is format-converted, and the format-converted access request is sent to the target device based on the address information of the target device.

[0023] In some embodiments, the driver information deployed in the container of the target device is a driver instruction set obtained by parsing the driver information corresponding to the central processing unit architecture supported by the target device.

[0024] In some embodiments, the method further includes:

[0025] If it is determined that a new physical machine has been added to the cluster, a container is deployed in the new physical machine. The container includes driver information corresponding to the central processing unit architecture supported by the physical machine. When the new physical machine is determined to be a target device by the first electronic device, it receives an access request sent by the first electronic device and sends the driver information in the container to the second electronic device corresponding to the access request.

[0026] Secondly, this application provides a central processing unit-driven invocation device applied to a first electronic device, the device comprising:

[0027] A receiving unit is configured to receive an access request sent by a second electronic device, wherein the access request is used to indicate a request to obtain driving information;

[0028] The determining unit, based on the access request, determines the physical machine with the driving information among the physical machines contained in the cluster as the target device;

[0029] A sending unit is used to send the access request to the target device; wherein the driver information in the target device is used to send to the second electronic device; the cluster includes multiple physical machines, at least one of the multiple physical machines supports a different central processing unit architecture than the central processing unit architectures supported by the other physical machines; each physical machine has a container deployed with driver information corresponding to the central processing unit architecture supported by the physical machine.

[0030] In some embodiments, the first electronic device has a plurality of first interfaces, wherein physical machines with different driving information correspond to different first interfaces, and physical machines with the same driving information correspond to the same first interface; the access request is specifically used to indicate the driving information of the physical machine corresponding to the first interface; the receiving unit is specifically used for:

[0031] Based on the first interface, the access request sent by the second electronic device is received;

[0032] Determine the unit, specifically for:

[0033] Based on the first interface, the physical machine corresponding to the first interface is determined as the target device among the physical machines included in the cluster;

[0034] The sending unit is specifically used to send the access request to the target device based on the first interface.

[0035] In some embodiments, the container in the physical machine has tag information, which is used to indicate the central processing unit architecture type corresponding to the driver information stored in the container; the first interface has an interface name; the determining unit is specifically used for:

[0036] Based on the first interface, according to the tag information of each container in the cluster, the interface name of the first interface, and the preset correspondence, the physical machine corresponding to the first interface is determined, and the physical machine corresponding to the first interface is determined as the target device. The preset correspondence is used to indicate the correspondence between the interface name of the first interface and the tag information.

[0037] In some embodiments, the first interface corresponds to multiple physical machines; the determining unit includes...

[0038] The first determining module is used to determine the physical machine corresponding to the first interface as a candidate device among the physical machines included in the cluster, based on the first interface.

[0039] The second determining module is used to obtain the network traffic occupancy of the candidate device and the number of access requests currently received by the first interface based on the first interface, and determine the target device corresponding to the access request among the candidate devices based on the network traffic occupancy of the candidate device and the number of access requests currently received by the first interface.

[0040] In some embodiments, the first electronic device has a second interface, which is a presentation layer state transition interface; the sending unit includes:

[0041] The sending module is used to send the address information of the target device and the access request to the second interface in the first electronic device based on the first interface;

[0042] The conversion module is used to perform format conversion processing on the access request based on the second interface, and send the format-converted access request to the target device based on the address information of the target device.

[0043] In some embodiments, the driver information deployed in the container of the target device is a driver instruction set obtained by parsing the driver information corresponding to the central processing unit architecture supported by the target device.

[0044] In some embodiments, the apparatus further includes:

[0045] The deployment unit is configured to deploy a container on a newly added physical machine if it is determined that a new physical machine has been added to the cluster. The container includes driver information corresponding to the central processing unit architecture supported by the physical machine. The newly added physical machine is configured to receive an access request sent by the first electronic device when it is identified as a target device by the first electronic device, and send the driver information in the container to the second electronic device corresponding to the access request.

[0046] Thirdly, this application provides an electronic device, including: a memory and a processor;

[0047] Memory; memory for storing executable instructions of the processor;

[0048] The processor is configured to execute the method as described in any of the first aspects according to the executable instructions.

[0049] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any of the first aspects.

[0050] Fifthly, this application provides a computer program product comprising a computer program that, when executed by a processor, implements the method described in any one of the first aspects.

[0051] This application provides a method, apparatus, and device for invoking a central processing unit (CPU) driver. The invocation method is applied to a first electronic device. The method includes: receiving an access request sent by a second electronic device, wherein the access request indicates a request to obtain driver information; based on the access request, determining a physical machine with the driver information among the physical machines in a cluster as a target device, and sending the access request to the target device; wherein the driver information in the target device is used to send to the second electronic device; the cluster includes multiple physical machines, at least one of which supports a CPU architecture different from the CPU architectures supported by the other physical machines; each physical machine has a container deployed with driver information corresponding to the CPU architecture supported by that physical machine. This method allows multiple physical machines to be deployed in the cluster, and different driver information to be set between different physical machines. When the second electronic device needs to invoke driver information, it can send an access request to the first electronic device, so that the first electronic device can find the physical machine with the driver information indicated by the access request in the cluster, and then the determined physical machine (i.e., the aforementioned target device) sends the driver information to the second electronic device. Using the above method, each second electronic device supporting different central processing unit architectures can access the first electronic device to call the driver information they need, avoiding the complex process of users sifting through massive amounts of publicly available information to find the driver information they need, and improving the efficiency of the second electronic device in calling driver information. Attached Figure Description

[0052] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0053] Figure 1 A flowchart illustrating a method for invoking a central processing unit driver, provided in an embodiment of this application;

[0054] Figure 2 A flowchart illustrating the second method for invoking a central processing unit driver provided in this application;

[0055] Figure 3 A schematic diagram of a cluster architecture provided in an embodiment of this application;

[0056] Figure 4 A schematic diagram of the structure of a central processing unit driver invoking device provided in an embodiment of this application;

[0057] Figure 5 A schematic diagram of the structure of another central processing unit driver invocation device provided in an embodiment of this application;

[0058] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0059] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0060] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.

[0061] Currently, with the continuous development of electronic technology, there are increasingly more types of central processing unit (CPU) architectures, such as RISC-V, ARM, x86, and Loongarch. Since different CPU architectures correspond to different driver information, electronic devices need to install driver information corresponding to the CPU architecture configured within the device to control connected peripherals. Specifically, the CPU can convert instructions sent to peripherals into instructions that the peripherals can recognize, or it can convert instructions returned by peripherals into instructions that the CPU can recognize. In practical applications, this driver information can be understood as a binary driver program. For example, when an electronic device needs to connect to a printer, the CPU in the device needs to configure the printer's binary driver program, and this configured binary driver program must correspond to the CPU architecture. Only then can the CPU convert the data to be printed or print control instructions into data or instructions that the printer can recognize, thus enabling the CPU to control the printer. Therefore, how to install and invoke CPU drivers is a problem that urgently needs to be solved.

[0062] In related technologies, users can access driver information by searching for it online. However, due to the large amount of information available online, users are unable to accurately filter out the driver information they actually need, leading to driver information retrieval failures.

[0063] The method, apparatus, and device for invoking a central processing unit driver provided in this application are intended to solve the aforementioned technical problems.

[0064] Explanation of technical terms:

[0065] A container is a runtime instance of an image. Just as a virtual machine can be launched from a virtual machine template, a user can also launch one or more containers from a single image. The biggest difference between virtual machines and containers is that containers are faster and more lightweight—unlike virtual machines, which run on top of a full operating system, containers share the operating system / kernel of their host (e.g., a physical machine in this example can be considered the host).

[0066] A pod is a logical wrapper entity used to execute containers on a cluster. You can think of each pod as a transparent wrapper that provides a slot for containers. A pod can contain one or more containers with shared storage / network resources. In practice, a cluster can run a group of related or unrelated pods; that is, a cluster can contain many related or unrelated pods, grouped within logical boundaries called namespaces.

[0067] A Node is a node that exists between a pod and a cluster. Essentially, it is a machine that hosts pods. Each node has some necessary services to run pods, whether physical or virtual.

[0068] A Service is a strategy for accessing pods within a cluster. Pods in a Kubernetes cluster have a lifecycle and are not revivable. Each pod has its own IP address, and the destruction and creation of a pod will generate a new IP address. Services are used to uniformly manage and track changes to these pods. Even if a pod changes, the foreground is unaware of the changes and no modifications are required. Services are responsible for service discovery and load balancing.

[0069] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0070] Figure 1 This is a flowchart illustrating a method for invoking a central processing unit driver, as provided in an embodiment of this application. The method provided in this embodiment is applied to a first electronic device and includes the following steps:

[0071] S101, Receive an access request sent by a second electronic device, wherein the access request is used to indicate a request to obtain driver information.

[0072] For example, the method for invoking the central processing unit (CPU) driver provided in this embodiment can be applied to a first electronic device. The second electronic device is the device that needs to invoke driver information. When the second electronic device needs to invoke driver information corresponding to the CPU architecture in the second electronic device, it can send an access request to the first electronic device to request the acquisition of the driver information corresponding to the CPU architecture in the second electronic device.

[0073] In one example, when the second electronic device sends an access request, the access request may directly carry the name of the required driver information so that the first electronic device can determine the driver information required by the second electronic device based on the name in the access request; or, the second electronic device may carry the CPU architecture type supported by the second electronic device in the access request so that the first electronic device can determine the driver information required by it based on the CPU architecture supported by the second electronic device.

[0074] S102. Based on the access request, determine the physical machine with driver information among the physical machines in the cluster as the target device, and send the access request to the target device; wherein, the driver information in the target device is used to send to the second electronic device; the cluster includes multiple physical machines, and at least one of the physical machines supports a different central processing unit architecture than the central processing unit architectures supported by the other physical machines; a container containing driver information corresponding to the central processing unit architecture supported by the physical machine is deployed in the physical machine.

[0075] For example, the cluster in this embodiment includes multiple physical machines. Each physical machine can be configured with a container, and the container stores driver information (also known as binary drivers) corresponding to the CPU architecture supported by that physical machine. Furthermore, at least one physical machine in the cluster supports a different CPU architecture than the others. For instance, in practical applications, the cluster in this embodiment can be a Kubernetes cluster. Kubernetes (often abbreviated as K8s) is an open-source system for automatically deploying, scaling, and managing containerized applications. This cluster can have four physical machines, one of which supports CPU architecture A, and the other three can support CPU architecture B. The physical machine supporting architecture A can store driver information A corresponding to architecture A, and the physical machine supporting architecture B can store driver information B corresponding to architecture B. It should be noted that one or more containers storing the same driver information can be configured on the same physical machine. Setting up multiple containers can improve the resource access rate of the physical machine, that is, increase the number of access requests that the physical machine can receive simultaneously. It should be noted that this embodiment does not specifically limit the type of cluster; the Kubernetes cluster mentioned in the example above can be used, or other clusters can be employed.

[0076] In one example, when the first electronic device determines the target device in the cluster, it can first determine the type of driver information contained in each physical machine, compare the determined driver information with the type of driver information indicated in the received access request, and take the physical machine where the first driver information with the matching result is located as the target device.

[0077] In this embodiment, after the first electronic device receives the access request sent by the second electronic device, the first electronic device will determine the physical machine with the driver information indicated by the access request as the target device among the multiple physical machines in the cluster based on the received access request. Then, the first electronic device will send the received access request to the target electronic device so that the target device can send the driver information in the target device to the second electronic device so that the second electronic device can retrieve the driver information it needs.

[0078] It is understood that in this embodiment, multiple physical machines can be deployed in the cluster, and among these physical machines (i.e., multiple hardware devices, such as multiple computer devices or multiple server devices), at least one physical machine contains driver information that differs from the driver information contained in the other physical machines. When a second electronic device needs to access driver information, it can send an access request to the first electronic device. The first electronic device can then find the physical machine in the cluster that contains the driver information indicated by the access request, and subsequently send the driver information to the second electronic device through the determined physical machine (i.e., the aforementioned target device). Using this method, each second electronic device supporting various central processing unit architectures can access the first electronic device to access the driver information it needs, avoiding the complex process of users sifting through massive amounts of publicly available information to find the required driver information, thus improving the efficiency of the second electronic device in accessing driver information.

[0079] Figure 2 This is a flowchart illustrating the second method for invoking a central processing unit (CPU) driver provided in this application. In this embodiment, the first electronic device has multiple first interfaces. Physical machines with different driver information correspond to different first interfaces, while physical machines with the same driver information correspond to the same first interface. The access request specifically indicates the driver information of the physical machine corresponding to the requested first interface. Figure 2 As shown, the method includes the following steps:

[0080] S201. Based on the first interface, receive the access request sent by the second electronic device.

[0081] For example, in this embodiment, a first electronic device may be provided with multiple first interfaces. The number of first interfaces corresponds to the number of types of driver information contained in the cluster. Furthermore, when setting up first interfaces in the first electronic device, multiple physical machines with the same driver information can each be provided with one first interface, and the types of driver information contained in the physical machines corresponding to different first interfaces are different. Each first interface can be used to receive access requests for the driver information contained in its corresponding physical machine.

[0082] For example, Figure 3 This is a schematic diagram of a cluster architecture provided for an embodiment of this application. Figure 3As shown in the diagram, this example uses a Kubernetes cluster. The cluster includes four physical machines. Physical machines 1 and 3 contain the same driver information (driver information A); physical machines 2 and 4 contain the same driver information (driver information B). Each physical machine can be considered a Node worker node in the Kubernetes cluster; the containers within each physical machine can be considered pods in the Kubernetes cluster. Therefore, when setting the first interface, two first interfaces can be set: first interface 1 and first interface 2 in the diagram. First interface 1 corresponds to physical machines 1 and 3, and first interface 2 corresponds to physical machines 2 and 4. When the second electronic device needs to access driver information B, it can send the access request to first interface 2; when it needs to request driver information 1, it can send the access request to first interface 1. In practical applications, the first interface in the first electronic device can be considered a Service in the Kubernetes cluster. Its implementation principle can be found in the relevant technical descriptions, and will not be elaborated here.

[0083] In other words, in this embodiment, multiple first interfaces are set in the first electronic device. Each first interface is responsible for receiving access requests that need to obtain the driver information contained in the physical machine corresponding to it. Therefore, when the second electronic device needs to call the driver information, it only needs to call the first interface in the first electronic device that corresponds to the driver information.

[0084] S202. Based on the first interface, the physical machine corresponding to the first interface in the cluster is identified as the target device; wherein, the driver information in the target device is used to send to the second electronic device; the cluster includes multiple physical machines, and at least one of the multiple physical machines supports a different central processing unit architecture than the central processing unit architectures supported by the other physical machines; a container containing driver information corresponding to the central processing unit architecture supported by the physical machine is deployed in the physical machine.

[0085] For example, in this embodiment, after the first interface in the first electronic device receives the access request, it will take the physical machine in the cluster corresponding to the first interface as the target device.

[0086] In some embodiments, when the first interface determines the target device, a polling method can be used to determine the current target device, or a random selection method can be used to select the target device.

[0087] It is understood that in this embodiment, the same first interface can be set for physical machines with the same driver information, and the driver information of physical machines corresponding to different first interfaces is different. Therefore, compared with setting a first interface for each physical machine, the first interface setting method provided in this embodiment can reduce the number of first interfaces exposed by the first electronic device, making it easier for the second electronic device to call the first interface. In addition, since different first interfaces correspond to different physical machines with different driver information, by adopting the above-mentioned first interface setting method, in the selection of target devices by the first interface, it is only necessary to select in the physical machine corresponding to the first interface, instead of selecting in all physical machines in the cluster, thereby improving the efficiency of driver information retrieval.

[0088] In one example, the container in the physical machine has tag information, which indicates the CPU architecture type corresponding to the driver information stored in the container; the first interface has an interface name; when executing step S202, it can be implemented through the following method:

[0089] Based on the first interface, the physical machine corresponding to the first interface is determined according to the tag information of each container in the cluster, the interface name of the first interface, and the preset correspondence. The physical machine corresponding to the first interface is then identified as the target device. The preset correspondence is used to indicate the correspondence between the interface name of the first interface and the tag information.

[0090] For example, in this embodiment, the containers contained in the physical machine have tag information, and the tag information of each container can represent the CPU architecture type corresponding to the driver information stored in the container. For instance, when the CPU architecture type corresponding to the driver information contained in the container in the physical machine is architecture A, the tag information of the container can be set to tag A. When the CPU architecture type corresponding to the driver information contained in the container in the physical machine is architecture B, the tag information of the container can be set to tag B. In addition, each first interface also has its own interface name, and the interface name and corresponding tag information of each first interface can be pre-stored in the first electronic device. When the first interface needs to determine the target device, the first interface can obtain the tag information of the containers contained in each physical machine, determine the container with the tag information corresponding to the interface name of the first interface, and determine the physical machine with the above-mentioned container as the target device.

[0091] In this embodiment, when determining the target device, the target device can be determined based on the tag information of the container contained in the first interface and the physical machine, so that the driving information required by the second electronic device can be accurately found.

[0092] In one example, the first interface corresponds to multiple physical machines; step S202 includes the following steps:

[0093] The first step of step S202: Based on the first interface, among the physical machines included in the cluster, determine the physical machine corresponding to the first interface as the candidate device.

[0094] The second step of step S202: Based on the first interface, obtain the network traffic usage of the candidate devices and the number of access requests currently received by the first interface, and determine the target device corresponding to the access request among the candidate devices according to the network traffic usage of the candidate devices and the number of access requests currently received by the first interface.

[0095] For example, in this embodiment, when the first interface corresponds to multiple physical machines, when determining the target device, all physical machines corresponding to the first interface can first be identified as candidate devices. It is understood that the first interface can simultaneously receive access requests from multiple second electronic devices. After receiving an access request, the first interface can obtain the network traffic usage of each candidate device and determine the number of access requests currently received by the first interface. In one example, the network traffic usage corresponding to a candidate device can be determined through the log records of the candidate device. By filtering the log records for the number of access requests currently being processed by the candidate device, the network traffic usage of that candidate device can be determined.

[0096] The first interface obtains the network traffic usage of each candidate device and the number of currently received access requests to determine the target device corresponding to each access request. For example, devices with high network traffic usage among multiple candidate devices can be deleted, and then the final target device can be selected from the remaining candidate devices.

[0097] It is understood that in this embodiment, when accessing the target device corresponding to the request, the network traffic occupancy of each physical machine corresponding to the first interface can be obtained. Based on the obtained network traffic occupancy of each physical machine and the number of access requests received in the first interface, the target device corresponding to each access request received by the first interface can be determined. This avoids the target device being unable to send the driver information to the second electronic device corresponding to the access request in a timely manner when the network traffic occupancy of the target device corresponding to the access request is high.

[0098] In one possible implementation, the first electronic device can determine the working status of each physical machine in the cluster, including: normal working status and stopped working status. Specifically, the first electronic device can determine the number of access requests received by each first interface at preset time intervals. Combined with the maximum network traffic usage supported by each physical machine, the working status of each physical machine in the cluster is determined. For example, if the number of access requests received by first interface 1 is less than a first preset value within a certain period, the working status of some physical machines corresponding to first interface 1 can be set to stopped working status. This avoids multiple physical machines simultaneously having low network traffic usage for a period of time, increases the network traffic usage of each physical machine, and thus avoids unnecessary resource consumption by the physical machines.

[0099] S203. The first electronic device has a second interface, which is a presentation layer state transition interface; based on the first interface, the address information of the target device and the access request are sent to the second interface in the first electronic device.

[0100] S204. Based on the second interface, perform format conversion processing on the access request, and send the format-converted access request to the target device based on the address information of the target device.

[0101] For example, in this embodiment, the first electronic device is also equipped with a second interface, which is a RESTful Application Program Interface (RESTful API). When the first interface receives an access request, it can send the received access request to the second interface in the first electronic device. The second interface is pre-set with constraints on the access request to perform format conversion processing on the received access request and send the format-converted access request to the target device. This allows the target device in the cluster to accurately identify the received access request and send the driver information stored in the target device to the second electronic device that sent the access request. Furthermore, when the first interface sends an access request to the second interface, it also sends the address information of the target device determined by the first interface to the second interface. This allows the second interface to perform format conversion processing on the access request and then send the format-converted access request to the target device based on the target device's address information. It should be noted that in this embodiment, there is no specific limitation on the number of second interfaces; one or more second interfaces can be set.

[0102] In one possible implementation, the second interface in the first electronic device can also be used to receive access requests sent by the second electronic device. After converting the access request into a different format, the access request is then sent to the first interface that needs to send it, and the first interface determines the target device.

[0103] It is understood that, in this embodiment, by setting a second interface, access requests from different second electronic devices can be converted into access requests of the same format, so that the target device in the cluster can accurately send the driver information to the second electronic device.

[0104] In some embodiments, based on any of the above embodiments, in this embodiment, the driver information deployed in the container of the target device is a driver instruction set obtained by parsing the driver information corresponding to the central processing unit architecture supported by the target device.

[0105] For example, in this embodiment, to improve the efficiency of installing driver information in the second electronic device, the driver information pre-stored in the container of the target device is a driver instruction set obtained by parsing the driver information corresponding to the central processing unit architecture supported by the target device. That is, the container in this embodiment is used to store the driver instruction set. When the target device sends driver information to the second electronic device, the target device can directly send the parsed driver instruction set to the second electronic device. After receiving the driver instruction set, the second electronic device can directly perform the installation process, thereby saving the cumbersome step of parsing the driver information.

[0106] In some embodiments, based on any of the above embodiments, if it is determined that a newly added physical machine exists in the cluster, a container is deployed in the newly added physical machine. The container includes driver information corresponding to the central processing unit architecture supported by the physical machine. The newly added physical machine is used to receive an access request sent by the first electronic device when it is determined to be a target device by the first electronic device, and send the driver information in the container to the second electronic device corresponding to the access request.

[0107] For example, in this embodiment, the first electronic device can also monitor the physical machines contained in the cluster in real time. When the first electronic device determines that a new physical machine has joined the cluster, the first electronic device can first determine the central processing unit architecture supported by the physical machine, and based on the central processing unit architecture, deploy a container to the newly joined physical machine, and deploy the driver information corresponding to the central processing unit architecture supported by the physical machine to the container.

[0108] Furthermore, in one possible implementation, when the CPU architecture supported by the newly added physical machine is different from that supported by any physical machine in the cluster, the first electronic device can also set a first interface corresponding to the physical machine in the first electronic device, so that the second electronic device can obtain the driver information in the newly added physical machine by sending an access request to the newly added first interface.

[0109] In this embodiment, by setting the same first interface for physical machines with the same driver information, and by providing different driver information for physical machines corresponding to different first interfaces, the first interface setting method provided in this embodiment reduces the number of first interfaces exposed by the first electronic device compared to setting a first interface for each physical machine, thus facilitating the second electronic device to call the first interface. Furthermore, since different first interfaces correspond to different driver information for different physical machines, using the above-mentioned first interface setting method, in selecting target devices through the first interface, it is only necessary to filter within the physical machine corresponding to the first interface, rather than filtering across all physical machines in the cluster, thereby improving the efficiency of driver information retrieval.

[0110] Figure 4 This application provides a schematic diagram of a central processing unit-driven invocation device, which is applied to a first electronic device and includes:

[0111] The receiving unit 41 is used to receive an access request sent by the second electronic device, wherein the access request is used to indicate a request to obtain driving information;

[0112] The determination unit 42, based on the access request, determines the physical machine with driver information among the physical machines contained in the cluster as the target device;

[0113] Sending unit 43 is used to send an access request to a target device; wherein, the driver information in the target device is used to send to a second electronic device; the cluster includes multiple physical machines, at least one of the physical machines supports a different central processing unit architecture than the other physical machines; a container containing driver information corresponding to the central processing unit architecture supported by the physical machine is deployed in the physical machine.

[0114] The apparatus provided in this embodiment is used to implement the technical solution provided by the above method. Its implementation principle and technical effect are similar, and will not be described again.

[0115] In some embodiments, the first electronic device has multiple first interfaces, wherein physical machines with different driving information correspond to different first interfaces, and physical machines with the same driving information correspond to the same first interface; the access request is specifically used to indicate the driving information of the physical machine corresponding to the first interface; the receiving unit 41 is specifically used for:

[0116] Based on the first interface, it receives access requests sent by the second electronic device;

[0117] Unit 42 is specifically used for:

[0118] Based on the first interface, the physical machine corresponding to the first interface is identified as the target device among the physical machines contained in the cluster;

[0119] The sending unit 43 is specifically used to send the access request to the target device based on the first interface.

[0120] In some embodiments, the container in the physical machine has tag information, which is used to indicate the central processing unit architecture type corresponding to the driver information stored in the container; the first interface has an interface name; the determining unit 42 is specifically used for:

[0121] Based on the first interface, the physical machine corresponding to the first interface is determined according to the tag information of each container in the cluster, the interface name of the first interface, and the preset correspondence. The physical machine corresponding to the first interface is then identified as the target device. The preset correspondence is used to indicate the correspondence between the interface name of the first interface and the tag information.

[0122] Figure 5 This is a schematic diagram of the structure of another central processing unit driver invocation device provided in an embodiment of this application. Figure 4 Based on the structure shown, the first interface corresponds to multiple physical machines; the determining unit 42 includes...

[0123] The first determining module 421 is used to determine the physical machine corresponding to the first interface as a candidate device among the physical machines included in the cluster, based on the first interface;

[0124] The second determining module 422 is used to obtain the network traffic occupancy of the candidate devices and the number of access requests currently received by the first interface based on the first interface, and determine the target device corresponding to the access request among the candidate devices based on the network traffic occupancy of the candidate devices and the number of access requests currently received by the first interface.

[0125] In some embodiments, the first electronic device has a second interface, which is a presentation layer state transition interface; the sending unit 43 includes:

[0126] The sending module 431 is used to send the address information of the target device and the access request to the second interface in the first electronic device based on the first interface;

[0127] The conversion module 432 is used to perform format conversion processing on the access request based on the second interface, and send the format-converted access request to the target device based on the address information of the target device.

[0128] In some embodiments, the driver information deployed in the container of the target device is a driver instruction set obtained by parsing the driver information corresponding to the central processing unit architecture supported by the target device.

[0129] In some embodiments, the apparatus further includes:

[0130] Deployment unit 44 is used to deploy a container in a newly added physical machine if it is determined that a new physical machine has been added to the cluster. The container includes driver information corresponding to the central processing unit architecture supported by the physical machine. When the newly added physical machine is determined to be a target device by the first electronic device, it receives an access request sent by the first electronic device and sends the driver information in the container to the second electronic device corresponding to the access request.

[0131] The apparatus provided in this embodiment is used to implement the technical solution provided by the above method. Its implementation principle and technical effect are similar, and will not be described again.

[0132] This application provides an electronic device, including: a memory and a processor;

[0133] Memory; memory used to store processor-executable instructions;

[0134] The processor is used to execute methods according to executable instructions.

[0135] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 6 As shown,

[0136] An exemplary electronic device 600 is illustrated, which can perform some or all of the mechanisms and actions described above. The exemplary electronic device 600 may include, but is not limited to, one or more central processing units (CPUs) 620, system memory 630, and a system bus 621 that couples various system components, including the system memory, to the processing unit 620. The system bus 621 can be any type of bus architecture among a variety of bus architectures, including a memory bus or memory controller, peripheral bus, and local bus using any of a variety of bus architectures. The electronic device 600 may optionally include graphics hardware, including but not limited to a graphics hardware interface 660 and a display device 661, which may include a display device capable of receiving touch-based user input, such as a touch-sensitive or multi-touch-enabled display device. Depending on the specific physical implementation, one or more of the CPU 620, system memory 630, and other components of the electronic device 600 may be physically juxtaposed, such as on a single chip. In this case, some or all of the system bus 621 may simply be silicon pathways within a single-chip structure, and its... Figure 6 The illustrations in the text may be symbolic descriptions for illustrative purposes only.

[0137] Electronic device 600 typically also includes computer-readable media, which can include any available medium accessible by electronic device 600 and includes volatile and non-volatile media as well as removable and non-removable media. By way of example, and not limitation, computer-readable media can include computer storage media and communication media. Computer storage media includes media implemented using any method or technique for storing content such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other storage technologies, CD-ROM, Digital Universal Disk (DVD) or other optical disc storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired content and is accessible by electronic device 600. However, computer storage media does not include communication media. Communication media typically embodies computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and includes any content delivery medium. By way of example, and not limitation, communication media includes wired media such as wired networks or direct wired connections, and wireless media such as acoustic, RF, infrared, and other wireless media. Any combination of the above should also be included within the scope of computer-readable media.

[0138] System memory 630 includes computer storage media in the form of volatile and / or non-volatile memory, such as read-only memory (ROM) 631 and random access memory (RAM) 632. A basic input / output system 633 (BIOS), containing basic routines that facilitate the transfer of content between components within electronic device 600, such as during startup, is typically stored in ROM 631. RAM 632 typically contains data and / or program modules that are immediately accessible and / or currently being operated by processing unit 620. This is by way of example and not limitation. Figure 6 The operating system 634, other program modules 635, and program data 636 are shown.

[0139] Electronic device 600 may also include other removable / non-removable volatile / non-volatile computer storage media. This is merely an example. Figure 6 The illustration depicts a hard disk drive 641 that reads from or writes to a non-removable, non-volatile magnetic medium. Other removable / non-removable volatile / non-volatile computer storage media that may be used with the exemplary electronic device include, but are not limited to, magnetic tape cassettes, flash memory cards, digital multifunction disks, digital videotapes, solid-state RAM, solid-state ROM, and other computer storage media defined and described above. The hard disk drive 641 is typically connected to the system bus 621 via a non-volatile memory interface such as interface 640.

[0140] The above discussion and Figure 6 The driver and its associated computer storage medium illustrated in the diagram provide storage for computer-readable instructions, data structures, program modules, and other data for electronic device 600. Figure 6 For example, hard disk drive 641 is illustrated as storing operating system 644, other program modules 645, and program data 646. Note that these components may be the same as or different from operating system 634, other program modules 635, and program data 636. Operating system 644, other program modules 645, and program data 646 are given different numbers here to indicate that they are at least different copies.

[0141] Electronic device 600 can operate in a network environment using a logical connection to one or more remote computers. Electronic device 600 is illustrated as being connected to a general network connection 651 (to network 670) via a network interface or adapter 650, which in turn is connected to a system bus 621. In the network environment, program modules depicted relative to electronic device 600 or parts thereof or peripheral devices can be stored in the memory of one or more other electronic devices communicatively coupled to electronic device 600 via general network connection 661. It should be understood that the network connection shown is exemplary, and other methods of establishing communication links between electronic devices can be used.

[0142] Although described as a single physical device, the exemplary electronic device 600 can be a virtual electronic device, in which case the functionality of the aforementioned physical components (such as CPU 620, system memory 630, network interface 640, and other similar components) can be provided by computer-executable instructions. Such computer-executable instructions can execute on a single physical electronic device or can be distributed across multiple physical electronic devices, including dynamically distributed across multiple physical electronic devices, such that the specific physical electronic device hosting such computer-executable instructions can dynamically change over time based on demand and availability. In the case where the exemplary electronic device 600 is a virtualized device, the underlying physical electronic device hosting such a virtualized electronic device may itself include physical components similar to those described above and operate in a similar manner. Furthermore, virtual electronic devices can be utilized in multiple layers, with one virtual electronic device executing within the construction of another virtual electronic device. Therefore, as used herein, the term "electronic device" refers to a physical electronic device or a virtualized computing environment, including a virtual electronic device, where computer-executable instructions can be executed in a manner consistent with the way instructions are executed on a physical electronic device. Similarly, as used herein, the term referring to physical components of an electronic device refers to those physical components or their virtualizations that perform the same or equivalent functions. Furthermore, the logic instructions in the aforementioned memory 630 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0143] The memory 630, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this application. The CPU 620 executes functional applications and data processing by running the software programs, instructions, and modules stored in the memory 630, thereby implementing the methods in the above-described method embodiments.

[0144] The memory 630 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 630 may include high-speed random access memory and may also include non-volatile memory.

[0145] This application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement any of the methods.

[0146] This application provides a computer program product, which includes a computer program that, when executed by a processor, implements any of the methods.

[0147] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0148] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0149] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0150] These computer program instructions may also be stored in a computer-readable storage medium capable of directing a computer or other programmable data processing terminal device to operate in a predictive manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0151] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0152] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

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

[0154] The foregoing has provided a detailed description of a method, apparatus, and device for invoking a central processing unit driver 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 above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

[0155] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the appended claims.

[0156] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for invoking a central processing unit driver, characterized in that, The method is applied to a first electronic device, the first electronic device having multiple first interfaces, wherein physical devices with different driving information have different first interfaces, and physical devices with the same driving information have the same first interface; the method includes: Based on the first interface, an access request sent by a second electronic device is received, wherein the access request is used to indicate the driving information of the physical machine corresponding to the first interface; Based on the first interface, among the physical machines included in the cluster, the physical machine corresponding to the first interface is identified as the target device, and the access request is sent to the target device; wherein, the driver information in the target device is used to send to the second electronic device; the cluster includes multiple physical machines, and at least one of the multiple physical machines supports a different central processing unit architecture than the central processing unit architectures supported by the other physical machines; the physical machine is equipped with a container that includes driver information corresponding to the central processing unit architecture supported by the physical machine.

2. The method according to claim 1, characterized in that, The containers in the physical machine have tag information, which is used to indicate the central processing unit architecture type corresponding to the driver information stored in the container; the first interface has an interface name; The step of determining the physical machine corresponding to the first interface as the target device among the physical machines included in the cluster, based on the first interface, includes: Based on the first interface, according to the tag information of each container in the cluster, the interface name of the first interface, and the preset correspondence, the physical machine corresponding to the first interface is determined, and the physical machine corresponding to the first interface is determined as the target device. The preset correspondence is used to indicate the correspondence between the interface name of the first interface and the tag information.

3. The method according to claim 1, characterized in that, The first interface corresponds to multiple physical machines; The step of determining the physical machine corresponding to the first interface as the target device among the physical machines included in the cluster, based on the first interface, includes: Based on the first interface, among the physical machines included in the cluster, the physical machine corresponding to the first interface is determined as a candidate device; Based on the first interface, the network traffic usage of the candidate devices and the number of access requests currently received by the first interface are obtained. Based on the network traffic usage of the candidate devices and the number of access requests currently received by the first interface, the target device corresponding to the access request is determined among the candidate devices.

4. The method according to claim 1, characterized in that, The first electronic device has a second interface, which is a presentation layer state transition interface; sending the access request to the target device includes: Based on the first interface, the address information of the target device and the access request are sent to the second interface in the first electronic device; Based on the second interface, the access request is format-converted, and the format-converted access request is sent to the target device based on the address information of the target device.

5. The method according to claim 1, characterized in that, The driver information deployed in the container of the target device is a set of driver instructions obtained by parsing the driver information corresponding to the central processing unit architecture supported by the target device.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: If it is determined that a new physical machine has been added to the cluster, a container is deployed in the new physical machine. The container includes driver information corresponding to the central processing unit architecture supported by the physical machine. When the new physical machine is determined to be a target device by the first electronic device, it receives an access request sent by the first electronic device and sends the driver information in the container to the second electronic device corresponding to the access request.

7. A central processing unit-driven invocation device, characterized in that, Applied to a first electronic device, the first electronic device having multiple first interfaces, wherein physical machines with different driving information correspond to different first interfaces, and physical machines with the same driving information correspond to the same first interface; the device includes: A receiving unit is configured to receive an access request sent by a second electronic device based on the first interface, wherein the access request is used to indicate the driving information of the physical machine corresponding to the first interface; The determining unit, based on the first interface, determines the physical machine corresponding to the first interface as the target device among the physical machines included in the cluster; A sending unit is used to send the access request to the target device; wherein the driver information in the target device is used to send to the second electronic device; the cluster includes multiple physical machines, at least one of the multiple physical machines supports a different central processing unit architecture than the central processing unit architectures supported by the other physical machines; each physical machine has a container deployed with driver information corresponding to the central processing unit architecture supported by the physical machine.

8. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, It stores a computer program, which is executed by a processor to implement the method as described in any one of claims 1-6.

10. A computer program product comprising a computer program that, when executed by a processor, implements the method as described in any one of claims 1-6.

Images