Driver program delay loading method of plug-and-play device and related product

Abstract

The invention provides a drive program delay loading method of plug-and-play equipment and related products, and the method comprises the following steps: under the condition that a first notification that a first drive program of the plug-and-play equipment is installed is received, a control program modifies the starting type of the first drive program into a first type; under the condition that the starting type of the first drive program is a first type and it is detected that the second drive program operates normally, the starting type of the first drive program is modified from the first type to a second type, and the first drive program depends on the second drive program; and when the starting type of the first driving program is a second type and it is detected that the first driving program is not operated, starting the plug-and-play device, and loading the first driving program. By adopting the method and the device, the loading opportunity of the first driving program can be flexibly controlled, and the problem of loading failure caused by uncontrollable loading sequence of the first driving program is solved.

Description

Technical Field

[0001] The present application relates to the computer field, and in particular to a method for delaying loading a driver of a plug-and-play device and related products. Background Art

[0002] Plug and Play (PNP) technology is a standardized hardware management mechanism designed to simplify the installation and configuration of hardware devices (i.e. hardware devices that support plug and play) in computer systems. When a PNP device is connected to a computer, the operating system can automatically identify the device and automatically load the corresponding driver according to its hardware characteristics. At the same time, the operating system will dynamically allocate the required system resources, such as interrupt requests, input / output ports, and memory locations, to the PNP device to ensure that the PNP device can operate normally. The implementation of PNP technology greatly reduces the complexity of users manually configuring hardware devices and improves the availability and flexibility of the system.

[0003] With the widespread application of plug-and-play technology, the timing of driver loading has become particularly important. As a key interface between the operating system and hardware devices, the timing of driver loading directly affects the identification and function realization of the device. When a PNP device is connected to a computer, the operating system not only needs to quickly identify the device, but also must load the corresponding driver at the appropriate time to ensure that the device can operate normally. Currently, the timing of driver loading is mainly controlled by configuring its startup type. There are five startup types for driver loading, namely SERVICE_BOOT_START (driver loaded by the operating system loader), SERVICE_SYSTEM_START (driver loaded by the operating system when the operating system is initialized), SERVICE_AUTO_START (driver loaded by the service control manager), SERVICE_DEMAND_START (driver loaded on demand by the driver's PNP manager or service control manager) and SERVICE_DISABLED (driver is disabled and not loaded by the operating system loader, service control manager or PNP manager).

[0004] In the prior art, the timing of driver loading follows the following rules: (1) Drivers with a startup type of SERVICE_BOOT_START are loaded before drivers with a startup type of SERVICE_SYSTEM_START or SERVICE_AUTO_START; (2) When the startup types of multiple drivers are all SERVICE_BOOT_START or all SERVICE_SYSTEM_START, they are loaded in the order specified in their respective load order groups; (3) Drivers for child devices are loaded later than drivers for parent devices.

[0005] However, in the prior art, when the startup types of the driver of PNP device 1 (the first driver) and the driver of PNP device 2 (the second driver) are both SERVICE_AUTO_START and SERVICE_DEMAND_START (the startup types of the first driver and the second driver can be the same or different), if the first driver needs to rely on the successful loading of the second driver to work properly, and there is no clear parent-child relationship between PNP device 1 and PNP device 2, the operating system will randomly load these two drivers. This random loading order may cause the first driver to be loaded before the second driver, so that PNP device 1 cannot find the resources or functions it depends on, and finally cause the first driver to fail to load or PNP device 1 cannot work properly. Summary of the invention

[0006] The embodiment of the present application provides a method for delayed loading a driver for a plug-and-play device and related products, which can flexibly control the loading timing of the driver and solve the problem of driver loading failure caused by the uncontrollable driver loading order of the PNP device.

[0007] In a first aspect, the present application provides a method for delayed loading a driver of a plug-and-play device, the method comprising: Upon receiving a first notification that the first driver of the plug-and-play device has been installed, the control program modifies the startup type of the first driver to a first type, wherein the first type is used to indicate that loading of the first driver is prohibited; When the startup type of the first driver is the first type and it is detected that the second driver is running normally, the startup type of the first driver is changed from the first type to the second type, wherein the second type is used to indicate that the first driver is allowed to be loaded and the first driver depends on the second driver; When the startup type of the first driver is the second type and it is detected that the first driver is not running, the plug-and-play device is enabled and the first driver is loaded.

[0008] In the above scheme, firstly, by changing the startup type of the first driver to the first type immediately after the first driver is installed, that is, prohibiting the first driver from loading, the problem of loading failure caused by the first driver attempting to load when the second driver has not yet been loaded is avoided, wherein the first driver depends on the second driver. Then, after detecting that the second driver is running normally (the second driver has been successfully loaded), the startup type of the first driver is changed to the second type, that is, the first driver is allowed to load. This process ensures that the first driver is loaded on the premise that the second driver it depends on is successfully loaded and runs. Finally, when the startup type of the first driver is the second type and it is detected that the first driver is not running (the first driver is not successfully loaded), the plug-and-play device is enabled and the first driver is loaded. This dynamic loading mechanism ensures that the system can flexibly adjust the loading timing of the driver according to the actual running state, thereby effectively solving the problem of driver loading failure caused by the uncontrollable driver loading order.

[0009] Based on the first aspect, in a possible implementation manner, before enabling the plug-and-play device, the method further includes: releasing resources of the plug-and-play device.

[0010] In the above scheme, it is of great significance to release the resources of the plug-and-play device before enabling the plug-and-play device. On the one hand, this measure helps to clean up the system resources occupied by the plug-and-play device and provide a clean operating environment for the loading of the driver, thereby avoiding the failure or error of the driver loading caused by residual resources and ensuring that the driver can be loaded smoothly; on the other hand, releasing the resources of the plug-and-play device can avoid the situation where the resources occupied by the plug-and-play device are not correctly released during the startup process, thereby reducing the deadlock, resource leakage and other problems in the subsequent operation of the system, improving the stability of the system, and reducing the crash or performance degradation caused by improper resource management.

[0011] Based on the first aspect, in a possible implementation, after enabling the plug-and-play device, the method further includes: The startup type of the first driver of the plug-and-play device is changed from the second type to the first type. When the control program is executed again, if it is detected that the second driver is running normally, the startup type of the first driver is changed from the first type to the second type.

[0012] It should be understood that the operating system will reload the driver every time it restarts. If the startup type of the first driver is not modified to the first type after the plug-and-play device is enabled and the first driver is successfully loaded, then the first driver will be reloaded after the operating system restarts. In this case, since the startup type of the first driver is still the second type and the first driver has been installed before, the control program will no longer receive the first notification that the first driver has been installed. This will result in the startup type of the first driver being unable to be modified to the first type. Since the second driver that the first driver depends on has not yet been loaded, if an attempt is made to load the first driver in this case, this may cause the first driver to fail to load. Therefore, this solution can ensure that the first driver will not be automatically loaded each time the operating system starts by immediately modifying its startup type to the first type after successfully loading the first driver, and the first driver is only allowed to be loaded when the control program detects that the second driver is running normally. This mechanism effectively avoids the problem of driver loading failure caused by the uncontrollable driver loading order.

[0013] Based on the first aspect, in a possible implementation, the method further includes: When the startup type of the first driver is the second type and it is detected that the first driver is running normally, the startup type of the first driver is changed from the second type to the first type; when the control program is executed again, when it is detected that the second driver is running normally, the startup type of the first driver is changed from the first type to the second type.

[0014] In the above scheme, during the process of starting the control program, the first driver may have been successfully loaded and started to run normally. If the control program is re-executed at this time, it may try to load the first driver again. However, by detecting that the first driver is running normally, the control program can confirm that the first driver has been successfully loaded and there is no problem, thereby avoiding unnecessary repeated loading. This can save system resources, improve efficiency, and avoid unnecessary operations. In addition, by introducing the check of the state of the first driver in the control program, the execution logic of the control program is optimized. The control program no longer loads the driver from the beginning every time, but decides whether to continue or skip the loading process by detecting whether it has been successfully loaded. This optimization enables the control program to work more efficiently and does not cause unnecessary duplication of work when it is executed or re-entered multiple times. When the control program detects that the first driver is running normally, it changes the startup type of the first driver from the second type to the first type, which can ensure that the driver will not be automatically loaded after the system is restarted.

[0015] In a second aspect, the present application provides a device for delaying loading a driver of a plug-and-play device, comprising: a modification module, configured to modify the startup type of the first driver to a first type upon receiving a first notification that the first driver of the plug-and-play device has been installed, wherein the first type is used to indicate that loading of the first driver is prohibited; The modification module is further used for, when the startup type of the first driver is the first type and it is detected that the second driver is running normally, modifying the startup type of the first driver from the first type to the second type, wherein the second type is used to indicate that the first driver is allowed to be loaded and the first driver depends on the second driver; The control module is used for enabling the plug-and-play device and loading the first driver when the startup type of the first driver is the second type and it is detected that the first driver is not running.

[0016] Based on the second aspect, in a possible implementation, before enabling the plug-and-play device, the control module is configured to release resources of the plug-and-play device.

[0017] Based on the second aspect, in a possible implementation, after the plug-and-play device is enabled, a modification module is used to change the startup type of the first driver of the plug-and-play device from the second type to the first type, and when the control program is executed again, when it is detected that the second driver is running normally, the startup type of the first driver is changed from the first type to the second type.

[0018] Based on the second aspect, in a possible implementation, a modification module is used to, when the startup type of the first driver is the second type, and when it is detected that the first driver is running normally, modify the startup type of the first driver from the second type to the first type; when the control program is executed again, when it is detected that the second driver is running normally, modify the startup type of the first driver from the first type to the second type.

[0019] In a third aspect, the present application provides a computing device, which includes a processor and a memory, wherein the processor is used to execute instructions stored in the memory so that the computing device implements the method described in the first aspect and any possible implementation method of the first aspect.

[0020] In a fourth aspect, the present application provides a computing device cluster, comprising at least one computing device, each computing device comprising a processor and a memory, the processor of at least one computing device being used to execute instructions stored in the memory of at least one computing device, so that the computing device cluster implements the method described in the first aspect and any possible implementation method of the first aspect.

[0021] In a fifth aspect, the present application provides a computer program product comprising instructions, which, when executed by a computing device cluster, enables the computing device cluster to execute the method described in the first aspect and any possible implementation of the first aspect. The computer program product may be a software installation package, and when the method provided by any possible design of the first aspect is needed, the computer program product may be downloaded and executed on the computing device cluster to implement the method described in the first aspect and any possible implementation of the first aspect.

[0022] In a sixth aspect, the present application provides a computer-readable storage medium, including computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes the method described in the first aspect or any possible implementation of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following briefly introduces the drawings required for describing the embodiments.

[0024] Figure 1 A flowchart of a method for delayed loading a driver for a plug-and-play device provided in this application; Figure 2 A schematic diagram of the structure of a device for delaying the loading of a driver program for a plug-and-play device provided in the present application; Figure 3 A schematic diagram of the structure of a computing device provided for this application; Figure 4 A schematic diagram of the structure of a computing device cluster provided in this application. DETAILED DESCRIPTION

[0025] A PNP device is a hardware device that can be automatically recognized and configured by the operating system after being inserted into a computer without manual intervention by the user. The main features of PNP devices include: (1) Automatic recognition: When a PNP device is connected to a computer, the operating system can automatically detect the presence of the device. (2) Resource allocation: The operating system automatically allocates necessary hardware resources to the PNP device, such as interrupt requests, input / output address ports, memory addresses, etc., to ensure that the device can work properly. (3) Driver loading: The operating system automatically loads the corresponding driver based on the type and characteristics of the PNP device so that the device can be used immediately. (4) Dynamic management: Users can add or remove PNP devices at any time while the computer is running, and the operating system will automatically handle these changes to ensure the stability and compatibility of the operating system. Common PNP devices include but are not limited to USB flash drives, mice, keyboards, printers, and network adapters.

[0026] In a specific scenario, there are PNP device 1 and PNP device 2, and PNP device 1 and PNP device 2 meet the following conditions: (1) The startup type of the driver of PNP device 1 (first driver) and the driver of PNP device 2 (second driver) are both SERVICE_AUTO_START and SERVICE_DEMAND_START, where the startup types of the first driver and the second driver can be the same or different. (2) The first driver needs to rely on the successful loading of the second driver before it can be loaded successfully. (3) There is no parent-child relationship between PNP device 1 and PNP device 2. For example, PNP device 1 can be a USB printer, and PNP device 2 can be a USB hub. Regarding PNP device 1 and PNP device 2, this application does not make specific restrictions, as long as the above three conditions are met.

[0027] In the prior art, for this scenario, the operating system may load the two drivers in a random order, which may cause the first driver to be loaded before the second driver, thereby causing the first driver to fail to load or the PNP device 1 to fail to operate normally. Therefore, in order to solve the problem in this scenario, it is necessary to implement delayed loading of the first driver to ensure that the second driver is loaded normally before loading the first driver, thereby ensuring the normal operation of the PNP device 1.

[0028] It should be noted that the present application is applicable to the case where two or more PNP devices meet the above three conditions, for example, the first driver depends on the second driver, and the second driver depends on the third driver (the driver of PNP device 3). In this case, first, it is necessary to implement delayed loading for the first driver and the second driver, and then, after confirming that the third driver is loaded normally, load the second driver; finally, after confirming that the second driver is loaded normally, load the first driver. For the convenience of description, the present application embodiment takes the first driver depending on the second driver as an example for introduction.

[0029] It should also be noted that, in addition to being applied to local computing environments such as laptops, desktops, etc., this application can also be applied to cloud computing environments such as cloud desktops, cloud application servers, etc. This solution is not specifically limited in the application scenario.

[0030] Next, the process of how the first driver in the above described scenario implements delayed loading is introduced in combination with specific process steps.

[0031] See also Figure 1 , Figure 1A flowchart of a method for delaying loading a driver of a plug-and-play device provided in the present application is provided. The method is applied to a Windows operating system. The method for delaying loading a driver of a plug-and-play device in the present embodiment includes: S101: upon receiving a first notification that the first driver program has been installed, the control program modifies the startup type of the first driver program to a first type.

[0032] When the PNP device (PNP device 1) corresponding to the first driver is a standardized device with simpler functions, such as a USB mouse, keyboard, USB wireless network card, USB flash drive, etc., the operating system will usually automatically identify and download the first driver after the PNP device 1 is inserted into the computer. Specifically: the operating system will detect the connection of the PNP device 1, read the hardware ID or device descriptor of the device, and then search for the first driver in the pre-stored driver library according to the hardware ID of the device. If the first driver is found, it will be installed. If the first driver is not found, the operating system will try to download and install the first driver from the driver repository, Windows Update or other sources; when the PNP device 1 is a device with complex functions that requires a dedicated driver to fully exert its performance, such as an audio interface, graphics card, etc., the user will usually actively install the first driver before the PNP device 1 is inserted into the computer.

[0033] In one implementation, the control program may use a device interface provided by the operating system, such as the RegisterDeviceNotification function of Windows, to register a notification processing program so as to receive a first notification of completion of the installation of the first driver when the installation of the first driver is completed.

[0034] It should be understood that in addition to using the device interface provided by the operating system to receive the first notification of completion of the installation of the first driver, the control program can also use other methods to receive the first notification of completion of the installation of the first driver, for example, through a custom communication mechanism between the control program and the first driver to receive the first notification of completion of the installation of the first driver, etc. This application does not make any specific limitations on this.

[0035] After receiving the first notification that the first driver has been installed, the control program needs to modify the startup type of the first driver to the first type to delay the loading of the first driver and wait until an appropriate time to load the first driver. The first type is used to indicate that the loading of the first driver is prohibited, and the first type can be SERVICE_DISABLED.

[0036] In one implementation, the control program modifies the startup type of the first driver in the Windows registry, and modifies the startup type of the first driver to the first type (SERVICE_DISABLED), and the specific steps are as follows: first, the control program opens the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ through the Windows application programming interface (API) or the registry operation function, wherein this path is the registry path containing all system services and driver configurations; then, the control program finds the corresponding key value of the first driver under the path (i.e., [first driver]), wherein each driver has a corresponding subkey under this path for storing configurations related to the driver; finally, the control program modifies the value of the Start configuration item under the key value to 4, i.e., SERVICE_DISABLED (indicating that the driver is disabled to prevent it from being automatically loaded when the operating system starts). For example, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\[first driver]Start = 4 (SERVICE_DISABLED).

[0037] It should be understood that in addition to modifying the startup type of the first driver to the first type in the Windows registry, the control program can also use other methods to modify the startup type of the first driver to the first type. For example, the control program can also modify the startup type of the first driver through Windows Management Instrumentation (WMI). This application does not make specific limitations on this.

[0038] S102: When the startup type of the first driver is the first type and it is detected that the second driver is running normally, modify the startup type of the first driver from the first type to the second type.

[0039] Among them, the first driver depends on the second driver (the driver of PNP device 2), which means that the second driver needs to be in a normal operating state before the first driver is loaded. When the status of the second driver is normal operation, it means that the second driver has been successfully loaded. If the first driver is loaded at this moment, the situation where the first driver fails to start due to the second driver not being loaded correctly can be avoided.

[0040] In one implementation, the control program can detect whether the second driver is running normally through a command line tool, such as devcon status [PNP device 2]. If the output result of devcon status is Driver is running, it means that the second driver has been successfully loaded and is in a normal working state. If the output result of devcon status is Device is disabled, it means that the second driver has not been successfully loaded or has failed to load.

[0041] It should be understood that the control program can also obtain the running status of the second driver program in other ways. For example, the control program can also call Windows API or detect the running status of the second driver program in other ways (such as event monitoring mechanism). This solution does not make specific limitations on this.

[0042] When the control program detects that the second driver is operating normally, the start type of the first driver is modified from the first type to the second type, wherein the second type is used to indicate that the first driver is allowed to be loaded, and the second type can be SERVICE_DEMAND_START, which means that the first driver is no longer automatically loaded when the operating system is started, but the driver is loaded by the driver's PNP manager or service control manager as needed, such as the first driver is loaded after the second driver is successfully loaded. For specific operating steps, please refer to the description of the control program modifying the start type of the first driver to the first type in S101, which will not be repeated here for the sake of simplicity of the patent. When the control program modifies the start type of the first driver to the second type in the Windows registry, the value of Start is modified to 3.

[0043] It should be understood that in addition to modifying the startup type of the first driver from the first type to the second type when detecting that the second driver is running normally, the control program can also set a delay time to load the first driver after a certain period of time has passed after the startup type of the first driver is modified to the first type, thereby ensuring that the first driver can be loaded normally, wherein the present application does not make any specific restrictions on the delay time. The present application does not make any specific restrictions on the timing when the control program modifies the startup type of the first driver from the first type to the second type.

[0044] S103: When the startup type of the first driver is the second type, the control program determines whether the first driver runs normally.

[0045] When the startup type of the first driver is set to the second type, the first driver is allowed to load. However, in actual applications, there is a situation: the control program may have loaded the first driver when it was first executed, and the driver may be suddenly forced to exit and restart after loading. When the control program is restarted, the subsequent steps will be executed again from S102. If the control program does not judge the running state of the first driver at this time, the first driver may be repeatedly loaded. Repeated loading of the first driver will not only waste system resources, but also cause multiple instances of the first driver to coexist in the system, which may cause conflicts, resource competition or memory leaks, thereby affecting the stability and performance of the system. Therefore, in order to avoid the above problems, the control program needs to first judge the running state of the first driver when determining that the startup type of the first driver is the second type. If the first driver is in a normal running state, it means that the first driver has been successfully loaded, and the control program should skip the operation of loading the first driver again to ensure that the first driver will not be repeatedly loaded. If the first driver is not in a running state, it means that the first driver has not been successfully loaded, and the control program controls the loading of the first driver.

[0046] The control program determines whether the first driver program is running normally. For reference to the description of the control program determining whether the second driver program is running normally in S102, for the sake of brevity of the patent, it will not be repeated here.

[0047] In the case that the startup type of the first driver is the second type, when the control program detects that the first driver is not running, S104 to S106 are executed, otherwise S106 is executed.

[0048] S104: The control program releases the resources of the PNP device 1.

[0049] The control program needs to release the resources of the PNP device 1 before loading the first driver program to avoid resource conflicts, driver errors or hardware initialization problems during the loading of the first driver program.

[0050] In one implementation, the control program may use the command line tool devcon (device management control tool) to perform a disabling operation on PNP device 1 to release the resources of PNP device 1, and the specific command is devcon disable [PNP device 1ID], where PNP device 1ID is an identifier of PNP device 1. This command notifies the operating system to disable PNP device 1, thereby releasing the system resources occupied by PNP device 1.

[0051] It should be understood that the control program using the command line tool devcon to release the resources of PNP device 1 is only an example. In actual applications, the control program can also use PowerShell scripts and other methods to disable PNP device 1 to release the resources of PNP device 1. This application does not make specific limitations on this.

[0052] S105: The control program enables the PNP device 1 and loads the first driver.

[0053] In one implementation, the control program can use the command line tool devcon to enable PNP device 1, and the specific command is devcon enable [PNP device 1 ID]. It should be understood that the control program uses the command line tool devcon to enable PNP device 1 only as an example. In actual applications, the control program can also use Windows API and other methods to enable PNP device 1, which is not specifically limited in this application. When PNP device 1 is successfully enabled, the first driver is loaded accordingly.

[0054] S106: The control program changes the startup type of the first driver program from the second type to the first type.

[0055] It should be understood that, since the startup type of the first driver has been changed from the first type to the second type before the first driver is successfully loaded, the startup type of the first driver is still the second type after each successful loading of the first driver. However, after the operating system is restarted, the control program will rerun. Since the startup type of the first driver is not the first type at this time, the control program will not be able to delay the loading of the first driver, which may cause the first driver to be loaded before the second driver is loaded, thereby causing the first driver to fail to load.

[0056] In order to avoid this situation, the startup type of the first driver needs to remain the first type each time the operating system is restarted. Therefore, in this application, after each successful loading of the first driver, the control program changes the startup type of the first driver from the second type to the first type. The specific implementation steps can be found in the description of S101, and for the sake of brevity of the patent, they will not be repeated here.

[0057] In summary, the present application provides a method for delayed loading of a driver for a plug-and-play device. First, upon receiving a first notification that the first driver of the plug-and-play device has been installed, the control program modifies the startup type of the first driver to the first type; then, when the startup type of the first driver is the first type and the second driver is detected to be running normally, the control program modifies the startup type of the first driver from the first type to the second type, wherein the first driver depends on the second driver; then, when the startup type of the first driver is the second type and the first driver is detected to be not running, the control program enables the plug-and-play device and loads the first driver. Finally, the control program modifies the startup type of the first driver from the second type to the first type. By implementing the present application, the loading timing of the first driver can be flexibly controlled to avoid the occurrence of the first driver loading failure due to the uncontrollable loading order of the first driver.

[0058] The present application provides a device for delaying loading a driver of a plug-and-play device, such as Figure 2 As shown, Figure 2 A schematic diagram of the structure of a device for delaying the loading of a driver program of a plug-and-play device provided in the present application includes: a modification module, configured to modify the startup type of the first driver to a first type upon receiving a first notification that the first driver of the plug-and-play device has been installed, wherein the first type is used to indicate that loading of the first driver is prohibited; The modification module is further used for, when the startup type of the first driver is the first type and it is detected that the second driver is running normally, modifying the startup type of the first driver from the first type to the second type, wherein the second type is used to indicate that the first driver is allowed to be loaded and the first driver depends on the second driver; The control module is used for enabling the plug-and-play device and loading the first driver when the startup type of the first driver is the second type and it is detected that the first driver is not running.

[0059] In a possible implementation, before enabling the plug-and-play device, the control module is used to release resources of the plug-and-play device.

[0060] In a possible implementation, after the plug-and-play device is enabled, a modification module is used to change the startup type of the first driver of the plug-and-play device from the second type to the first type. When the control program is executed again, if it is detected that the second driver is running normally, the startup type of the first driver is changed from the first type to the second type.

[0061] In a possible implementation, the modification module is used to, when the startup type of the first driver is the second type and, upon detecting that the first driver is operating normally, modify the startup type of the first driver from the second type to the first type; when the control program is executed again, upon detecting that the second driver is operating normally, modify the startup type of the first driver from the first type to the second type.

[0062] Among them, the modification module and the control module can be implemented by software or hardware. Exemplarily, the implementation of the modification module is introduced below by taking the modification module as an example. Similarly, the implementation of the control module can refer to the implementation of the modification module.

[0063] As an example of a software functional unit, a modification module may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the computing instance may be one or more. For example, the modification module may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple data centers with close geographical locations. Generally, a region may include multiple AZs.

[0064] Similarly, multiple hosts / virtual machines / containers used to run the code can be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Usually, a VPC is set up in a region. For cross-region communication between two VPCs in the same region and between VPCs in different regions, a communication gateway needs to be set up in each VPC to achieve interconnection between VPCs through the communication gateway.

[0065] As an example of a hardware functional unit, the modification module may include at least one computing device, such as a server, etc. Alternatively, the modification module may also be implemented using a central processing unit (CPU), an application-specific integrated circuit (ASIC), or a device implemented using a programmable logic device (PLD). The above-mentioned PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), a data processing unit (DPU), a neural network processing unit (NPU), a system on chip (SoC), an offload card, an acceleration card, or any combination thereof.

[0066] The multiple computing devices included in the modification module can be distributed in the same region or in different regions. The multiple computing devices included in the modification module can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the modification module can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, GALs, DPUs, NPUs, SoCs, offload cards, acceleration cards, etc.

[0067] It should be noted that, in other embodiments, the modification module can be used to execute any step in the delayed loading method of the driver of the plug-and-play device, and the control module can be used to execute any step in the delayed loading method of the driver of the plug-and-play device. The steps that the modification module and the control module are responsible for implementing can be specified as needed. The modification module and the control module respectively implement different steps in the delayed loading method of the driver of the plug-and-play device to realize all the functions of the delayed loading device of the driver of the plug-and-play device.

[0068] The present application also provides a computing device 100. Figure 3As shown, the computing device 100 includes: a bus 102, a processor 104, a memory 106, and a communication interface 108. The processor 104, the memory 106, and the communication interface 108 communicate with each other through the bus 102. The computing device 100 can be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in the computing device 100.

[0069] The bus 102 may be a peripheral component interconnect Express (PCIe) bus or an extended industry standard architecture (EISA) bus, a unified bus (Ubus or UB), a compute express link (CXL), a cache coherent interconnect for accelerators (CCIX), etc. Among them, the unified bus is also called a Lingqu bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 3 The bus 102 is represented by only one line, but it does not mean that there is only one bus or one type of bus. The bus 102 may include a path for transmitting information between various components of the computing device 100 (for example, the memory 106, the processor 104, and the communication interface 108). Among them, the unified bus may also be called a Lingqu bus.

[0070] The processor 104 may include any one or more computing devices such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP) or a digital signal processor (DSP), an ASIC, an FPGA, a CPLD, an NPU, a SoC, an offload card, an acceleration card, etc.

[0071] The memory 106 may include a volatile memory, such as a random access memory (RAM). The processor 104 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD) or a solid state drive (SSD). In addition, the memory 106 may also be implemented by a storage class memory (SCM), a phase change memory (PCM), or other types of storage media.

[0072] It is worth noting that the same type of storage medium can be configured in the same computing device to implement the function of memory 106, or two or more types of storage media can be configured to implement the function of memory 106, and this application does not limit this.

[0073] The memory 106 stores executable program codes, and the processor 104 executes the executable program codes to respectively implement the functions of the modification module and the control module, thereby implementing the driver delay loading method for the plug-and-play device. That is, the memory 106 stores instructions for executing the driver delay loading method for the plug-and-play device.

[0074] The communication interface 108 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 100 and other devices or a communication network.

[0075] As a possible implementation, the computing device 100 may include multiple types of processors 104, that is, the computing device 100 is a heterogeneous device, for example, the computing device 100 includes a CPU and a GPU, and at least one of the processors 104 may perform the operation steps corresponding to the method for delaying loading the driver of the plug-and-play device. For the sake of brevity, it will not be described in detail here.

[0076] The embodiment of the present application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smart phone.

[0077] like Figure 4As shown, the computing device cluster includes at least one computing device 100. The memory 106 in one or more computing devices 100 in the computing device cluster may store the same instructions for executing the driver delay loading method for the plug-and-play device.

[0078] In some possible implementations, the memory 106 of one or more computing devices 100 in the computing device cluster may also store partial instructions for executing the method for delaying loading the driver of the plug-and-play device. In other words, the combination of one or more computing devices 100 may jointly execute the instructions for executing the method for delaying loading the driver of the plug-and-play device.

[0079] It should be noted that the memory 106 in different computing devices 100 in the computing device cluster can store different instructions, which are respectively used to execute part of the functions of the driver delay loading device of the plug-and-play device. That is, the instructions stored in the memory 106 in different computing devices 100 can implement the functions of one or more modules in the modification module and the control module.

[0080] The embodiment of the present application also provides a computer program product including instructions. The computer program product may be software or a program product including instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes a method for delaying the loading of a driver of a plug-and-play device.

[0081] The embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by the computing device or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk). The computer-readable storage medium includes instructions that instruct the computing device to execute a driver delay loading method for a plug-and-play device.

[0082] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for delaying loading a driver of a plug-and-play device, characterized in that: The method comprises: Upon receiving a first notification that a first driver of a plug-and-play device has been installed, the control program modifies a startup type of the first driver to a first type, wherein the first type is used to indicate that loading of the first driver is prohibited; When the startup type of the first driver is the first type and it is detected that the second driver is running normally, the startup type of the first driver is changed from the first type to the second type, wherein the second type is used to indicate that the first driver is allowed to be loaded and the first driver depends on the second driver; When the startup type of the first driver is the second type and it is detected that the first driver is not running, the plug-and-play device is enabled and the first driver is loaded.

2. The method according to claim 1, characterized in that Before enabling the plug-and-play device, the method further includes: releasing resources of the plug-and-play device.

3. The method according to claim 1 or 2, characterized in that: After enabling the plug-and-play device, the method further includes: The startup type of the first driver of the plug-and-play device is changed from the second type to the first type. When the control program is executed again, if it is detected that the second driver is running normally, the startup type of the first driver is changed from the first type to the second type.

4. The method according to claim 1, characterized in that: The method further comprises: When the startup type of the first driver is the second type and it is detected that the first driver is running normally, the startup type of the first driver is changed from the second type to the first type; when the control program is executed again, when it is detected that the second driver is running normally, the startup type of the first driver is changed from the first type to the second type.

5. A device for delaying loading a driver of a plug-and-play device, characterized in that: The device comprises: a modification module, configured to modify the startup type of the first driver to a first type upon receiving a first notification that the first driver of the plug-and-play device has been installed, wherein the first type is used to indicate that the first driver is prohibited from being loaded; The modification module is further used for, when the startup type of the first driver is the first type and it is detected that the second driver is running normally, modifying the startup type of the first driver from the first type to a second type, wherein the second type is used to indicate that the first driver is allowed to be loaded and the first driver depends on the second driver; The control module is used for enabling the plug-and-play device and loading the first driver when the startup type of the first driver is the second type and it is detected that the first driver is not running.

6. The device according to claim 5, characterized in that Before enabling the plug-and-play device, the control module is used to release resources of the plug-and-play device.

7. The device according to claim 5 or 6, characterized in that After the plug-and-play device is enabled, the modification module is used to modify the startup type of the first driver of the plug-and-play device from the second type to the first type, and when the control program is executed again, if it is detected that the second driver is running normally, the startup type of the first driver is modified from the first type to the second type.

8. The device according to claim 5, characterized in that The modification module is used to modify the startup type of the first driver from the second type to the first type when the startup type of the first driver is the second type and it is detected that the first driver is running normally, and when the control program is executed again, when it is detected that the second driver is running normally, the startup type of the first driver is modified from the first type to the second type.

9. A computing device cluster, characterized in that: comprising at least one computing device, each computing device comprising a processor and a memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1 to 4.

10. A computer program product comprising instructions, characterized in that When the instructions are executed by a computing device cluster, the computing device cluster executes the method according to any one of claims 1 to 4.

11. A computer-readable storage medium, characterized in that: The method comprises computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster performs the method according to any one of claims 1 to 4.

Images