User mode driver management method, device, electronic device and storage medium

Abstract

The present application provides a user-mode driver management method, device, electronic device and storage medium, and relates to the technical field of driver resource management. The method includes: scanning the target device to be managed based on the user-mode driver, obtaining the application request of the target driver corresponding to the target device; performing mutual exclusion detection on the target resource of the target driver corresponding to each application request to obtain the detection result; based on the detection result, managing each target resource accordingly in the user-mode driver. The present application can linearize the concurrent application requests in multiple external devices on the basis of the user-mode driver, centrally detect the mutually exclusive resources between multiple application requests, manage each target resource independently, isolate errors between different drivers, reduce conflicts between multiple drivers in the user mode, improve the stability and availability of the user-mode driver management, and thus improve the management efficiency of the user-mode driver.

Description

Technical Field

[0001] The present application relates to the technical field of driver resource management, and in particular to a user-mode driver management method, device, electronic device and storage medium. Background Art

[0002] In the development process of the server, an important process is to develop drivers for the main components of the server, so as to facilitate the use of these hardware in subsequent application development. Device drivers can be divided into user-mode drivers and kernel-mode drivers. Most drivers usually run in kernel space, because interrupt processing and hardware resource mapping require privileges, and the corresponding privileges are only allowed in kernel space. However, kernel-mode drivers have problems such as large system call overhead, unstable kernel space API (Application Programming Interface), difficult debugging and maintenance, and errors are more likely to cause system crashes. Although there are problems such as interrupt processing when migrating device drivers from kernel state to user state, the trend of driving user state is the same.

[0003] Among the current user-mode driver methods, some are based on UIO (Userspace I / O, I / O technology running in user space), VFIO (user-mode driver framework), DPDK (Data Plane Development Kit) and similar framework design solutions and variant solutions, and some are U2MDF (Uni fied User-Mode Driver Framework) and similar design solutions that divide traditional device drivers into user-mode driver modules (User-Driver, referred to as UD) and kernel-mode driver modules (Kernel-Driver, referred to as KD). These methods can migrate part of the driver from kernel mode to user mode, but in the actual implementation of the prior art, there are many different drivers, the feasibility of implementing different drivers in user mode is low, the real-time management of user-mode drivers is low, resulting in low efficiency of user-mode driver management, and different drivers cannot use critical resources normally. Summary of the invention

[0004] In view of this, the purpose of the embodiments of the present application is to provide a user-mode driver management method, device, electronic device and storage medium to improve the problem of low efficiency of user-mode driver management in the prior art.

[0005] In order to solve the above problems, in a first aspect, the present application provides a user mode driver management method, comprising:

[0006] Scanning the target device to be managed based on the user mode driver to obtain the application request of the target driver corresponding to the target device;

[0007] Performing mutual exclusion detection on the target resource of the target driver corresponding to each of the application requests to obtain a detection result;

[0008] Based on the detection result, each of the target resources is managed accordingly in the user mode driver.

[0009] In the above implementation, the target drivers of one or more target devices are managed in the user state. The target device is scanned in the user state to obtain the application request corresponding to the target driver in the target device, and it is possible to detect whether there are mutually exclusive resources in one or more application requests, and manage the target resources corresponding to each application request separately according to the different detection results. Concurrent application requests in multiple external devices can be linearly and centrally detected, and each target resource can be managed independently to isolate errors between drivers of different devices, reduce the adverse effects caused by mutual exclusion of resources between different drivers, reduce conflicts between multiple drivers in the user state, improve the stability and availability of user state driver management, and thus improve the management efficiency of user state drivers.

[0010] Optionally, the detection result includes a time detection result and a type detection result, and the mutually exclusive detection is performed on the target resource of the target driver corresponding to each application request to obtain the detection result, including:

[0011] Create mutually exclusive resource tables based on preset resource parameters;

[0012] Based on the mutually exclusive resource table, the usage time of the target resource of the target drive corresponding to each application request is detected to obtain a time detection result, wherein the time detection result includes a long occupancy type and a short occupancy type;

[0013] Based on the mutually exclusive resource table, the return type of the target resource of the target driver corresponding to each application request is detected to obtain a type detection result, wherein the type detection result includes blocking and non-blocking.

[0014] In the above implementation, since the resources requested by multiple target drivers of multiple target devices are different, there may be mutually exclusive resources in multiple application requests. To ensure that each application request can run normally, multiple application requests can be centrally detected and processed. The duration and return type of the target resource requested by each application request are detected through the created resource table to detect whether there are mutually exclusive resources in the multiple target resources, and obtain time detection results and type detection results. Mutually exclusive resources can be detected from multiple aspects such as time and resource blocking, which improves the accuracy and efficiency of mutual exclusion detection.

[0015] Optionally, the correspondingly managing each of the target resources in the user-mode driver based on the detection result includes:

[0016] When the time detection result is a long occupancy type, when the occupancy time requested by the application exceeds a threshold, releasing the target resource;

[0017] When the type detection result is blocking, adding the target resource to a queue for waiting;

[0018] When the type detection result is non-blocking, feedback processing is performed on the target resource.

[0019] In the above implementation, according to the different detection results in the mutual exclusion detection, each target resource is correspondingly released, waited for, fed back and other processing methods are performed through the specific type in the detection result. Different application requests can be managed in parallel, and the target resources corresponding to each application request can be managed independently. When an error occurs in any target driver, the target driver can be isolated from other target drivers to reduce the adverse effects of the driver error on other drivers, so that the target device can work normally on the basis of the target resource processing, effectively improving the management efficiency of the user-mode driver.

[0020] Optionally, scanning the target device to be managed based on the user mode driver to obtain the application request of the target driver corresponding to the target device includes:

[0021] Get the device type of the target device to be managed;

[0022] Based on the device type, scanning the target device to determine whether a target driver corresponding to the target device exists;

[0023] When the target driver exists, reading the data packet of the target driver to obtain the corresponding data area;

[0024] When the target driver does not exist, creating a memory area of ​​the target driver;

[0025] Acquire a data area corresponding to a data packet of the target drive based on the memory area;

[0026] The data area is read to determine the application request corresponding to the target driver.

[0027] In the above implementation, when the user-mode driver manages the target device, the device type of one or more external target devices can be obtained first, and based on the device type, one or more target devices can be scanned to see if there is a corresponding target driver. When the target driver exists or does not exist, the shared data area of ​​the target device is obtained in different ways, the data area is read, a request processing process is created, and one or more application requests corresponding to the target driver in the target device are determined. The target drivers of multiple external devices can be independently processed in parallel or serially, and the type and working status of the target device can be accurately determined, so that the data area can be obtained in different ways to parse the application request in the target driver.

[0028] Optionally, after scanning the target device based on the device type, the method further includes:

[0029] Loading a device driver library corresponding to the target device;

[0030] When the device driver library is loaded successfully, releasing the driver resources occupied by the target driver;

[0031] When the device driver library fails to load, a loading error message is fed back.

[0032] In the above implementation, after scanning the target device, taking into account the hardware problems that may occur or already exist in the connected target device, it is also possible to apply for the device driver library corresponding to the target device, and release the driver resources with hardware problems in multiple target drivers based on the loading results of the device driver library, so as to delete the corresponding target driver, or add a new target driver to realize dynamic loading of the driver module, and in the driver management process, be able to monitor the hardware functions of the target device in real time, and add or delete the driver in time.

[0033] Optionally, before scanning the target device to be managed based on the user mode driver and obtaining the application request of the target driver corresponding to the target device, the method further includes:

[0034] Create corresponding uplink data channel and downlink data channel in user state;

[0035] Get the encapsulation data of the driver in kernel state;

[0036] Obtaining a corresponding downlink data packet based on the encapsulated data, and writing the downlink data packet into the downlink data channel;

[0037] Obtaining a corresponding uplink data packet based on the encapsulated data, and writing the uplink data packet into the uplink data channel;

[0038] A corresponding user-mode driver is determined based on the uplink data channel and the downlink data channel.

[0039] In the above implementation, before the user state driver manages different drivers, the driver management method can also be migrated, and the driver in the kernel state is migrated to the user state to obtain the corresponding user state driver. Corresponding uplink and downlink data channels are established in the user state to realize the migration of data in the two data channels. The encapsulated data of the target driver is obtained while maintaining the original driver interface of the kernel state unchanged, and the downlink data packet in the encapsulated data is written into the downlink data channel. When the migration request reaches the user state, the user state can unpack the encapsulated data packet, and encapsulate it according to the interface return to obtain the corresponding uplink data packet, and write the uplink data packet into the corresponding uplink data channel to obtain the corresponding user state driver, thereby realizing the creation and maintenance of the data channel, and improving the pertinence and stability of the driver when migrating from the kernel state to the user state.

[0040] Optionally, the method further comprises:

[0041] Creating a device driver library corresponding to the target device;

[0042] The user mode interface is connected to the interfaces of the plurality of device driver libraries to manage the plurality of target devices.

[0043] In the above implementation, in order to facilitate the management and expanded use of multiple external devices, when the driver migrates from kernel state to user state, a device database corresponding to each target device can also be created, and the kernel state interface can be connected to the interfaces of multiple device driver libraries to achieve docking between the server and the driver library, so that data can be exchanged between the user state driver and the target device in the form of a library. There is no need to rewrite the driver or program the hardware when using it, and the connected devices can be managed directly and quickly, thereby improving the efficiency of managing multiple devices.

[0044] Optionally, the method further comprises:

[0045] Encapsulating the reserved functions of the kernel state to obtain kernel state functions;

[0046] Functional requirements in the user-mode driver are managed based on the kernel-mode functions.

[0047] In the above implementation, since some drivers in the user-state driver have low fault tolerance, in order to ensure that the server can run and be managed normally, a part of the kernel-state functions are run during the management of the user-state driver, and the reserved functions are encapsulated to obtain the reserved kernel-state functions. On the basis of the kernel-state functions, the problems of low fault tolerance, low latency requirements, and inability to time that exist when the user-state driver is managed are solved, so as to manage the target device more accurately and timely and improve the management efficiency of the user-state driver.

[0048] In a second aspect, the present application further provides a user-mode driver management device, the device comprising:

[0049] A request module, used to scan the target device to be managed based on the user mode driver, and obtain the application request of the target driver corresponding to the target device;

[0050] A detection module, used for performing mutual exclusion detection on the target resource of the target driver corresponding to each application request to obtain a detection result;

[0051] A management module is used to manage each of the target resources accordingly in the user mode driver based on the detection result.

[0052] In the above implementation, the application request of the target device that needs to be managed is obtained on the basis of the user-mode driver management through the request module; the detection module detects whether there are mutually exclusive resources in the target resources requested by the target driver corresponding to each application request to obtain the detection result; the management module manages each target resource accordingly based on the detection result, and can perform linear and centralized detection of concurrent application requests in multiple external devices, manage each target resource independently, and isolate errors between drivers of different devices, reduce the adverse effects caused by mutual exclusion of resources between different drivers, reduce conflicts between multiple drivers in the user mode, and improve the stability and availability of user-mode driver management, thereby improving the management efficiency of user-mode drivers.

[0053] In a third aspect, the present application also provides an electronic device, comprising a memory and a processor, wherein the memory stores program instructions, and when the processor reads and runs the program instructions, it executes the steps in any implementation of the above-mentioned user-mode driver management method.

[0054] In a fourth aspect, the present application also provides a computer-readable storage medium, in which computer program instructions are stored. When the computer program instructions are read and executed by a processor, the steps in any implementation method of the above-mentioned user-mode driver management method are executed.

[0055] In summary, the present application provides a user-state driver management method, device, electronic device and storage medium, which can, based on the user-state driver, linearize the concurrent application requests in multiple external devices, centrally detect the mutually exclusive resources between multiple application requests, independently manage each target resource, isolate errors between different drivers, reduce conflicts between multiple drivers in the user state, improve the stability and availability of user-state driver management, and thus improve the management efficiency of user-state drivers. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments of the present application will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0057] Figure 1 A flowchart of a user mode driver management method provided in an embodiment of the present application;

[0058] Figure 2 A detailed flow chart of step S2 provided in an embodiment of the present application;

[0059] Figure 3 A detailed flow chart of step S3 provided in an embodiment of the present application;

[0060] Figure 4 A detailed flow chart of step S1 provided in an embodiment of the present application;

[0061] Figure 5 A detailed flowchart of another step S1 provided in an embodiment of the present application;

[0062] Figure 6 A flowchart of another user mode driver management method provided in an embodiment of the present application;

[0063] Figure 7 A schematic diagram of the structural modules of a user-mode driver management device provided in an embodiment of the present application.

[0064] Icons: 400 - user-mode driver management device; 410 - request module; 420 - detection module; 430 - management module. DETAILED DESCRIPTION

[0065] The technical scheme in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments of the embodiments of the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the embodiments of the present application.

[0066] The current user-mode drivers are generally based on UIO (Userspace I / O, I / O technology running in user space), VFIO (User-mode Driver Framework), DPDK (Data Plane Development Kit) and similar framework design solutions and variant solutions. Some are U2MDF (Unified User-Mode Driver Framework) and similar design solutions that divide traditional device drivers into user-mode driver modules (User-Driver, referred to as UD) and kernel-mode driver modules (Kernel-Driver, referred to as KD), for example:

[0067] The driver framework and variants built using UIO: By exporting two sets of user-mode interfaces, users can control devices in device nodes. The mapping interface is used to map device register space, the read-write interface is used to control interrupt shutdown / on, and the read interface is used to wait for a device interrupt.

[0068] Or, on the driver framework of U2MDF and its variants, the traditional device driver is divided into a user-mode driver module and a kernel-mode driver module. The kernel-mode driver module mainly contains performance-related hotspot codes and critical paths (such as interrupt handling functions, soft interrupts, frequently called functions, data copy functions, etc.), and runs in the kernel address space as a loadable kernel module. The user-mode driver module mainly contains performance-irrelevant cold-spot codes (such as device initialization, configuration, control, error handling, and occasionally called functions, etc.), and runs in the user address space as a process or a loadable dynamic shared library. The kernel-mode driver module is further divided into a kernel-driver core module (Kernel-DriverCORE, referred to as KD-CORE) and a kernel-driver communication module (Kernel-DriverCOM, referred to as KD-COM). KD-CORE completes the core functions of the kernel-mode driver module, such as interrupt handling, providing services for the user-mode driver module, etc.; KD-COM is mainly used to respond to and manage the communication between the kernel-mode driver module and the user-mode driver module. Similar to the kernel-state driver module, the user-state driver module is also divided into the user-driver core module (User-DriverCORE, abbreviated as UD-CORE) and the user-driver communication module (User-DriverCOM, abbreviated as UD-COM). UD-CORE completes the core functions of the user-driver module, such as device initialization, device configuration, error handling and other functions; UD-COM is mainly responsible for the interaction with the kernel-state driver module, such as requesting the kernel-state driver module to provide services, executing function call requests from the kernel-state driver module, etc.

[0069] However, in the above-mentioned prior art, although some drivers in kernel state can be migrated to user state, due to the existence of multiple different drivers, the feasibility of implementing different drivers in user state is low, and the real-time management of user state drivers is low, resulting in low efficiency of user state driver management, and different drivers cannot use critical resources normally.

[0070] Therefore, in order to solve the above problems, an embodiment of the present application provides a user-state driver management method, which is applied to a server. The server can be a personal computer (PC), a tablet computer, a smart phone, a personal digital assistant (PDA), and other electronic devices with logical computing functions. The server includes a kernel state and a user state, and can manage multiple different drivers based on the user-state driver to manage multiple external devices.

[0071] Optionally, the electronic device may include a memory, a storage controller, a processor, a peripheral interface, an input / output unit, etc. The components and structure of the electronic device may be arranged according to actual conditions.

[0072] The above-mentioned memory, storage controller, processor, peripheral interface, input and output unit components are directly or indirectly electrically connected to each other to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses or signal lines. The above-mentioned processor is used to execute the executable module stored in the memory.

[0073] The memory may be, but is not limited to, a random access memory (RAM), a read only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable read-only memory (EEPROM), etc. The memory is used to store programs, and the processor executes the program after receiving the execution instruction. The method executed by the electronic device defined by the process disclosed in any embodiment of the present application can be applied to the processor or implemented by the processor.

[0074] The above-mentioned processor may be an integrated circuit chip with signal processing capabilities. The above-mentioned processor may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The various methods, steps and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0075] The above-mentioned peripheral interface couples various input / output devices to the processor and the memory. In some embodiments, the peripheral interface, the processor and the memory controller can be implemented in a single chip. In some other examples, they can be implemented by separate chips respectively.

[0076] The electronic device in this embodiment can be used to execute each step in each user-mode driver management method provided in the embodiment of the present application. The implementation process of the user-mode driver management method is described in detail below through several embodiments.

[0077] See also Figure 1 , Figure 1 A flowchart of a user mode driver management method provided in an embodiment of the present application, the method may include the following steps:

[0078] Step S1, scanning a target device to be managed based on a user mode driver, and obtaining an application request of a target driver corresponding to the target device.

[0079] When performing management, the user-mode driver can obtain application requests generated by target drivers in subordinate target devices by scanning, so as to perform unified and centralized management on one or more application requests in one or more target devices.

[0080] Step S2: performing mutual exclusion detection on the target resources of the target driver corresponding to each of the application requests to obtain a detection result.

[0081] Among them, since multiple subordinate target drivers managed by the user-mode driver can only have mutually exclusive resources, it is necessary to centrally detect whether there are mutually exclusive resources in the target resources corresponding to the centrally managed application requests, and obtain the detection result of each target resource.

[0082] Step S3: Based on the detection result, each of the target resources is managed accordingly in the user mode driver.

[0083] Among them, since the detection results corresponding to multiple target resources are different, the mutual exclusion situation in each target resource can be judged according to the detection results, so that each target resource can be processed accordingly according to the mutual exclusion situation, thereby realizing independent management of each target resource, isolating multiple target drivers through independent management, and reducing the mutual influence between multiple target drivers.

[0084] exist Figure 1 In the illustrated embodiment, errors between drivers of different devices can be isolated, the adverse effects caused by resource mutual exclusion between different drivers can be reduced, conflicts between multiple drivers in user mode can be reduced, the stability and availability of user mode driver management can be improved, and the management efficiency of user mode drivers can be improved.

[0085] Optionally, the test results include time test results and type test results, see Figure 2 , Figure 2A detailed flow chart of step S2 provided in an embodiment of the present application, step S2 may also include steps S21-S23;

[0086] Step S21: creating a mutually exclusive resource table based on preset resource parameters.

[0087] When mutually exclusive resources are detected, the mutual exclusion situation in each resource can be recorded according to the resource parameters of each target resource, and a corresponding mutually exclusive resource table can be created to obtain the detection result of the mutual exclusion detection based on the table.

[0088] Optionally, the resource parameters may include the resource type of each target resource, such as audio, video, image, etc., and may also include resource related parameters such as the resource number of each target resource.

[0089] Step S22: Based on the mutually exclusive resource table, the usage time of the target resource of the target driver corresponding to each application request is detected to obtain a time detection result.

[0090] Among them, the time detection results include long occupancy type and short occupancy type. The long occupancy type is the driver that the resource occupies a long time in the data channel and exceeds the time threshold, and the short occupancy type is the driver that the resource occupies a short time and does not exceed the time threshold. In the mutually exclusive resource table, the time occupancy type of each target resource is classified according to the occupancy time of the resource in the data channel to obtain the time detection result of each target resource.

[0091] Optionally, the time threshold may be selected and adjusted according to user requirements and actual application conditions.

[0092] Step S23: detecting the return type of the target resource of the target driver corresponding to each application request based on the mutually exclusive resource table to obtain a type detection result.

[0093] The type detection results include blocking and non-blocking. Blocking means that the application request cannot be run, and non-blocking means that the application request can be run. In the mutually exclusive resource table, each target resource is classified according to the return type corresponding to each application request to obtain the corresponding type detection result.

[0094] It is worth noting that the mutual exclusion situation in the target resources can be detected in terms of both time and resource blocking, and the mutual exclusion situation in the target resources can also be detected by the priority of the target-driven delay situation.

[0095] exist Figure 2 In the illustrated embodiment, mutually exclusive resources can be detected from multiple aspects, thereby improving the accuracy and efficiency of mutual exclusion detection.

[0096] It is worth noting that, depending on the different detection results in the mutual exclusion detection, each target resource can be processed differently through the specific type in the detection result, so as to manage multiple target resources accordingly. Please refer to Figure 3 , Figure 3 A detailed flow chart of step S3 provided in an embodiment of the present application, step S3 may also include steps S31-S33:

[0097] Step S31: when the time detection result is a long occupancy type and the occupancy time requested by the application exceeds a threshold, the target resource is released.

[0098] Among them, when the target resource is occupied for a long time, the target resource can be forcibly released when the occupation time of the corresponding target driver exceeds the preset release threshold. When a certain driver occupies the data channel for a long time, due to the long occupation time, the target resource and other resources are mutually exclusive in time. By releasing the target resource, the existing mutually exclusive resources can be managed accordingly to reduce the impact on other drivers.

[0099] Optionally, during management, verification information may also be sent to the target driver corresponding to the application request. If the target driver provides feedback on the work progress within a preset time (e.g., 1 s), it means that the target resource corresponding to the target driver is working normally and there is no need to release the target resource. If the target driver does not provide feedback on the work progress within the preset time, it means that the target resource corresponding to the target driver is working abnormally and the target resource needs to be released to end the current work process of the target driver.

[0100] For example, the hardware functions of some target devices need to occupy SPIO for a long time for continuous configuration. After each configuration sub-process is completed, a signal needs to be sent to indicate that the working status is normal. The feedback information is used to determine whether the target device is working normally, thereby reducing the possibility of the target device being stuck.

[0101] Step S32: When the type detection result is blocking, the target resource is added to a queue for waiting.

[0102] Among them, when the return type of the application request is blocking, it means that there are many target drivers managed by the current user-mode driver. Therefore, when the upper-level application requests are called in parallel, multiple application requests can be added to the queue for queuing to reduce the conflict between the hardware resources in the same target device due to the parallel upper-level application requests, so that the target resources can wait in the queue and perform corresponding operations according to the order of the queue.

[0103] Optionally, when the return type of the application request is in a blocking state for a long time, or when the application request is detected as a blocking state multiple times during mutual exclusion detection, the return type of the application request can be converted to a non-blocking state to process the target resource in a timely manner.

[0104] Step S33: When the type detection result is non-blocking, feedback processing is performed on the target resource.

[0105] When the return type of the application request is non-blocking, it means that the mutually exclusive resource of the target resource is busy and feedback processing is required for the target resource. The server or user receives the feedback information and processes the target resource accordingly.

[0106] For example, target resources may also be managed accordingly according to the priority of target-driven delay conditions.

[0107] It is worth noting that, in order to improve the efficiency and accuracy of target resource management, the server may also include a manual function, allowing users to manually manage multiple target resources according to needs and actual conditions.

[0108] exist Figure 3 In the illustrated embodiment, different application requests can be managed in parallel, and the target resources corresponding to each application request can be managed independently. When an error occurs in any target driver, the target driver can be isolated from other target drivers, thereby reducing the adverse effects of the driver error on other drivers, so that the target device can work normally on the basis of target resource processing, effectively improving the management efficiency of user-mode drivers.

[0109] Optionally, see Figure 4 , Figure 4 A detailed flow chart of step S1 provided in an embodiment of the present application, step S1 may also include steps S11-S16;

[0110] Step S11, obtaining the device type of the target device to be managed;

[0111] Among them, since the types of target devices are different, the corresponding target drivers are also different. The device type can be obtained before scanning to perform targeted scanning.

[0112] Optionally, the device type may include a variety of different external devices such as LED lights, buzzers, and monitoring chips.

[0113] Step S12: Scan the target device based on the device type to determine whether a target driver corresponding to the target device exists.

[0114] Among them, it is possible to determine whether the target device currently has a corresponding target driver through scanning, so as to perform corresponding processing according to different scanning results.

[0115] Step S13: when the target drive exists, read the data packet of the target drive to obtain the corresponding data area.

[0116] When the target driver exists, the data packet of the target driver can be directly read to obtain the shared data area of ​​the upstream data corresponding to the target driver.

[0117] Step S14: when the target driver does not exist, create a memory area of ​​the target driver.

[0118] When the target driver does not exist, a shared memory for the upstream data in the target driver may be created, and the memory area is an upstream data area shared by multiple target drivers.

[0119] Step S15, acquiring a data area corresponding to the data packet of the target drive based on the memory area.

[0120] Wherein, the data area of ​​the uplink data of the data packet can be obtained based on the created shared memory area.

[0121] Optionally, when creating a shared data area, a static linked list corresponding to each target driver can be obtained in the memory area, and the static linked list includes N ring linked list head nodes and 1 recycle head node. On the basis of the static linked list, the working thread of the target driver is matched with the static linked list, and based on the upper layer application interface in the target driver, the uplink data in the static linked list is extracted according to the thread ID in the data packet header of the target driver, so as to process the linked list node of the lost packet in the uplink data.

[0122] Optionally, when acquiring the data area, since each target driver has a corresponding downstream FIFO (First Input First Output) memory, a FIFO memory for downstream data in the data packet of the target driver may also be created to store the downstream data.

[0123] Step S16, reading the data area to determine the application request corresponding to the target driver.

[0124] By reading the data area, a request processing flow can be created, and one or more upper-layer application requests corresponding to the target driver in the target device can be determined based on the uplink data.

[0125] exist Figure 4In the illustrated embodiment, target drivers of multiple external devices can be independently processed in parallel or serially, and the type and working status of the target device can be accurately determined to obtain data areas in different ways and parse application requests in the target driver.

[0126] Optionally, see Figure 5 , Figure 5 Another detailed flow diagram of step S1 provided in an embodiment of the present application, after step S12, step S1 may further include steps S17-S19;

[0127] Step S17, loading the device driver library corresponding to the target device.

[0128] Among them, after scanning the target device, considering the possible or existing hardware problems in the connected target device, it is also possible to monitor multiple threads of user-mode driver management by sending changes to the target driver, such as applying to load the device driver library corresponding to the target device when new additions or errors are added.

[0129] Step S18: when the device driver library is loaded successfully, the driver resources occupied by the target driver are released.

[0130] Among them, when the device driver library is loaded successfully, the FIFO memory of the downstream data corresponding to the target driver can be created or deleted to dynamically add or delete the target driver; multiple static linked lists in the data area of ​​the upstream data can also be cleared to release the mutually exclusive driver resources occupied by the target driver, thereby reducing the adverse effects of driver resources on other target drivers.

[0131] Step S19: When the device driver library fails to load, a loading error message is fed back.

[0132] When the device driver library fails to load, the server can feedback loading error information so that the user can adjust the hardware of the target device or manually manage the thread of the target driver.

[0133] exist Figure 5 In the illustrated embodiment, by dynamically loading the driver module, the hardware functions of the target device can be monitored in real time during the driver management process, and the driver can be added or deleted in a timely manner.

[0134] Optionally, see Figure 6 , Figure 6 A flowchart of another user-mode driver management method provided in an embodiment of the present application. Before step 1, the method may further include steps Sa1-Sa5;

[0135] Step Sa1, creating corresponding uplink data channels and downlink data channels in user mode.

[0136] Before the user-mode driver manages different drivers, the driver management mode can be migrated to migrate the driver in the kernel mode to the user mode. During the migration, two data channels, upstream and downstream, can be established to independently write the upstream data and downstream data in the driver.

[0137] Step Sa2, obtaining the encapsulation data of the driver in the kernel state.

[0138] Among them, the interface of the original kernel-state driver can be organized, and the internal functions can be rewritten while maintaining the original interface unchanged, and multiple functions can be encapsulated to obtain corresponding encapsulation data, so as to migrate the driver from kernel state to user state based on the encapsulated functions.

[0139] Step Sa3, obtaining a corresponding downlink data packet based on the encapsulated data, and writing the downlink data packet into the downlink data channel.

[0140] The corresponding downlink data packet is parsed from the encapsulated data, and the downlink data packet may include a command code, a thread ID, multiple types / lengths / values ​​and other data.

[0141] Step Sa4, obtaining a corresponding uplink data packet based on the encapsulated data, and writing the uplink data packet into the uplink data channel.

[0142] Among them, when the request for driver migration reaches the user state, the user state can unpack the encapsulated data packet, distribute it according to the command code in the data packet, and package it according to the interface return to obtain the corresponding uplink data packet. The uplink data packet may include command code, thread ID, return value, multiple types / lengths / values ​​and other data.

[0143] Step Sa5: determining a corresponding user-mode driver based on the uplink data channel and the downlink data channel.

[0144] The data is migrated in two data channels, and the driver in the kernel state is migrated to the user state to obtain the corresponding user state driver.

[0145] exist Figure 6 In the illustrated embodiment, the data channel can be created and maintained, thereby improving the pertinence and stability of the driver when migrating from kernel mode to user mode.

[0146] It is worth noting that when migrating the driver from kernel state to user state, a device driver library corresponding to the target device can also be created; the user state interface is connected to the interfaces of multiple device driver libraries to manage multiple target devices.

[0147] Among them, when migrating the driver, in order to improve the management efficiency of the driver, the use of kernel-state drivers can be reduced as much as possible by using memory-mapped files and other methods. For example, when the target device is an I2C bus, the I2Cdev method can be used for migration. During migration, in order to facilitate the management and expansion of multiple external devices, a device database corresponding to each target device can also be created, and the kernel-state interface can be connected to the interface of multiple device driver libraries to achieve the connection between the server and the driver library. After the connection, the multiple connected interfaces can be encapsulated to improve the stability of the interaction. Data interaction is carried out between the user-state driver and the target device in the form of a library, and there is no need to write the driver or program the hardware again when using it. The connected devices can be managed directly and quickly, and the efficiency of managing multiple devices can be improved.

[0148] For example, when creating a device driver library, the driver library can be written according to the hardware of the target driver of the target device. A device driver library may include one or more driver interfaces in the target device. The device driver library may include: init (initialization) interface, uninit (formatting) interface, get / read (get) interface; set / write (setting) interface, info (with feedback alarm) interface, trap (without feedback alarm) interface and other interfaces. Different target drivers can select one or more corresponding interfaces according to actual conditions.

[0149] It is worth noting that when migrating a driver from kernel state to user state, the reserved functions of kernel state can also be encapsulated to obtain kernel state functions; and the functional requirements in the user state driver can be managed based on the kernel state functions.

[0150] Among them, considering the actual application scenario of user-state driver management, after the driver is migrated, due to the low fault tolerance, high real-time and other characteristics of the user-state driver itself, it may cause certain risks to the operation of the server, resulting in the server restarting or crashing. In addition, due to the diversity of external device types, some functions in the kernel-state driver can be reserved to obtain reserved functions. The reserved functions can be selected and adjusted according to the actual needs of the user and the actual situation during application. The reserved functions can include multiple functions such as fault tolerance function, real-time function, delay requirement, timer function in the kernel state. On the basis of the obtained reserved functions, multiple functions are uniformly encapsulated so that the kernel-state function can be run in the kernel state. During operation, the kernel-state function can be used to manage the kernel-state function requirements encountered when managing the user-state driver through data interaction between the kernel-state function and the user-state driver, so as to solve the problems of low fault tolerance, low delay requirement, and inability to time when managing the user-state driver. It can solve kernel-mode related problems in user-mode drivers, ensure the normal operation and management of the server, make the management of user-mode drivers more stable and effective, achieve more accurate and timely management of target devices, and improve the management efficiency of user-mode drivers.

[0151] For example, when the target driver is a watchdog (a monitoring chip) or other driver with low fault tolerance, it is not suitable to be run in the original user-mode driver. It can be run by the kernel-mode timer function based on the kernel-mode function. When the target device is an LED light or a buzzer, the target driver has a low latency requirement and needs the kernel-mode timer function to control the target device in high real-time to reduce the lag or distortion of the light and buzzer. Therefore, it can also be run by the kernel-mode timer function based on the kernel-mode function.

[0152] Optionally, when reserving the reserved functions in the kernel state, the server can collect and control the resource occupancy when managing between the kernel state and the user state during the management of the user state driver, so as to manage the driver in a timely and accurate manner.

[0153] See also Figure 7 , Figure 7 A schematic diagram of a structural module of a user-mode driver management device provided in an embodiment of the present application, wherein the user-mode driver management device 400 includes:

[0154] The request module 410 is used to scan the target device to be managed based on the user mode driver and obtain the application request of the target driver corresponding to the target device;

[0155] A detection module 420, configured to perform a mutual exclusion detection on the target resource of the target driver corresponding to each application request to obtain a detection result;

[0156] The management module 430 is used to manage each of the target resources accordingly in the user mode driver based on the detection result.

[0157] In an optional implementation, the detection module 420 may further include a table building submodule, a time submodule and a type submodule;

[0158] The table creation submodule is used to create a mutually exclusive resource table based on preset resource parameters;

[0159] A time submodule, configured to detect the usage duration of the target resource of the target driver corresponding to each application request based on the mutually exclusive resource table, and obtain a time detection result, wherein the time detection result includes a long occupancy type and a short occupancy type;

[0160] The type submodule is used to detect the return type of the target resource of the target driver corresponding to each application request based on the mutually exclusive resource table to obtain a type detection result, wherein the type detection result includes blocking and non-blocking.

[0161] In an optional implementation, the management module 430 may further include a release submodule, a wait submodule and a feedback submodule;

[0162] A release submodule, configured to release the target resource when the time detection result is a long occupancy type and when the occupancy time requested by the application exceeds a threshold;

[0163] A waiting submodule, used for adding the target resource to a queue for waiting when the type detection result is blocking;

[0164] A feedback submodule is used to perform feedback processing on the target resource when the type detection result is non-blocking.

[0165] In an optional implementation, the request module 410 may further include an acquisition submodule, a scanning submodule, a region submodule, and a determination submodule;

[0166] The acquisition submodule is used to obtain the device type of the target device to be managed;

[0167] A scanning submodule, configured to scan the target device based on the device type to determine whether a target driver corresponding to the target device exists;

[0168] A region submodule, used for reading a data packet of the target driver to obtain a corresponding data region when the target driver exists;

[0169] The area submodule is further used to create a memory area of ​​the target driver when the target driver does not exist; and obtain a data area corresponding to a data packet of the target driver based on the memory area;

[0170] The reading submodule is used to read the data area to determine the application request corresponding to the target drive.

[0171] In an optional implementation, the user-mode driver management device 400 may further include a loading module for loading a device driver library corresponding to the target device; when the device driver library is loaded successfully, the driver resources occupied by the target driver are released; when the device driver library fails to load, loading error information is fed back.

[0172] In an optional embodiment, the user-state driver management device 400 may also include a migration module for creating a corresponding upstream data channel and a downstream data channel in the user state; obtaining encapsulation data of the driver in the kernel state; obtaining a corresponding downstream data packet based on the encapsulation data, and writing the downstream data packet into the downstream data channel; obtaining a corresponding upstream data packet based on the encapsulation data, and writing the upstream data packet into the upstream data channel; and determining a corresponding user-state driver based on the upstream data channel and the downstream data channel.

[0173] In an optional implementation, the user-mode driver management device 400 may further include a connection module for creating a device driver library corresponding to the target device; connecting the user-mode interface with multiple interfaces of the device driver library to manage the multiple target devices.

[0174] In an optional implementation, the user-mode driver management device 400 may further include a reservation module for encapsulating the kernel-mode reserved functions to obtain kernel-mode functions; and managing the functional requirements in the user-mode driver based on the kernel-mode functions.

[0175] Since the principle of solving the problem by the user-mode driver management device 400 in the embodiment of the present application is similar to that of the aforementioned embodiment of the user-mode driver management method, the implementation of the user-mode driver management device 400 in this embodiment can refer to the description in the embodiment of the aforementioned method, and the repeated parts will not be repeated.

[0176] An embodiment of the present application also provides an electronic device, which includes a memory and a processor, wherein the memory stores program instructions, and when the processor reads and runs the program instructions, it executes the steps of any one of the user-mode drive management methods provided in this embodiment.

[0177] It should be understood that the electronic device may be a personal computer, a tablet computer, a smart phone, a personal digital assistant, or other electronic device with logic computing capabilities.

[0178] An embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer program instructions. When the computer program instructions are read and executed by a processor, the steps of any one of the user-mode driver management methods provided in the present embodiment are executed.

[0179] In summary, the embodiments of the present application provide a user-state driver management method, device, electronic device and storage medium, which can, on the basis of user-state drivers, perform linear processing on concurrent application requests in multiple external devices, centrally detect mutually exclusive resources between multiple application requests, independently manage each target resource, isolate errors between different drivers, reduce conflicts between multiple drivers in user state, improve the stability and availability of user-state driver management, and thus improve the management efficiency of user-state drivers.

[0180] In several embodiments provided in the present application, it should be understood that the disclosed device can also be implemented in other ways. The device embodiments described above are merely schematic, for example, the block diagrams in the accompanying drawings show the possible architecture, functions and operations of the devices according to the multiple embodiments of the present application. In this regard, each box in the block diagram can represent a module, a program segment or a part of a code, and the module, a program segment or a part of the code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram, and the combination of the block diagrams, can be implemented with a dedicated hardware-based system that performs a specified function or action, or can be implemented with a combination of dedicated hardware and computer instructions.

[0181] In addition, the functional modules in the various embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

[0182] If the function is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Therefore, this embodiment also provides a computer program instruction stored in a readable storage medium, and when the computer program instruction is read and executed by a processor, the steps in any method described in the block data storage method are executed. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, RanDom Access Memory), disk or optical disk and other media that can store program codes.

[0183] The above description is only an embodiment of the present application and is not intended to limit the scope of protection of the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application should be included in the scope of protection of the present application. It should be noted that similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in the subsequent drawings.

[0184] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be covered by the protection scope of the present application.

[0185] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the statement "include..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

Claims

1. A user-mode driver management method, characterized in that: include: Scanning the target device to be managed based on the user mode driver to obtain the application request of the target driver corresponding to the target device; Performing mutual exclusion detection on the target resource of the target driver corresponding to each application request to obtain a detection result; Based on the detection result, managing each of the target resources accordingly in the user mode driver; Wherein, the detection result includes a time detection result and a type detection result, and the target resources of the target driver corresponding to each of the application requests are subjected to mutual exclusion detection to obtain the detection result, including: creating a mutual exclusion resource table based on preset resource parameters; based on the mutual exclusion resource table, detecting the usage time of the target resources of the target driver corresponding to each of the application requests to obtain the time detection result, wherein the time detection result includes a long occupancy type and a short occupancy type; based on the mutual exclusion resource table, detecting the return type of the target resources of the target driver corresponding to each of the application requests to obtain the type detection result, wherein the type detection result includes blocking and non-blocking.

2. The method according to claim 1, characterized in that: Based on the detection result, managing each of the target resources accordingly in the user mode driver includes: When the time detection result is a long occupancy type, when the occupancy time requested by the application exceeds a threshold, releasing the target resource; When the type detection result is blocking, adding the target resource to a queue for waiting; When the type detection result is non-blocking, feedback processing is performed on the target resource.

3. The method according to claim 1, characterized in that The scanning of the target device to be managed based on the user mode driver to obtain the application request of the target driver corresponding to the target device includes: Get the device type of the target device to be managed; Based on the device type, scanning the target device to determine whether a target driver corresponding to the target device exists; When the target driver exists, reading the data packet of the target driver to obtain the corresponding data area; When the target driver does not exist, creating a memory area of ​​the target driver; Acquire a data area corresponding to a data packet of the target drive based on the memory area; The data area is read to determine the application request corresponding to the target driver.

4. The method according to claim 3, characterized in that After scanning the target device based on the device type, the method further includes: Loading a device driver library corresponding to the target device; When the device driver library is loaded successfully, releasing the driver resources occupied by the target driver; When the device driver library fails to load, a loading error message is fed back.

5. The method according to claim 1, characterized in that Before scanning the target device to be managed based on the user mode driver and obtaining the application request of the target driver corresponding to the target device, the method further includes: Create corresponding uplink data channel and downlink data channel in user state; Get the encapsulation data of the driver in kernel state; Obtaining a corresponding downlink data packet based on the encapsulated data, and writing the downlink data packet into the downlink data channel; Obtaining a corresponding uplink data packet based on the encapsulated data, and writing the uplink data packet into the uplink data channel; A corresponding user-mode driver is determined based on the uplink data channel and the downlink data channel.

6. The method according to claim 5, characterized in that The method further comprises: Creating a device driver library corresponding to the target device; The user mode interface is connected to the interfaces of the plurality of device driver libraries to manage the plurality of target devices.

7. The method according to claim 5, characterized in that The method further comprises: Encapsulating the reserved functions of the kernel state to obtain kernel state functions; Functional requirements in the user-mode driver are managed based on the kernel-mode functions.

8. A user-mode driver management device, characterized in that: The device comprises: A request module, used to scan the target device to be managed based on the user mode driver, and obtain the application request of the target driver corresponding to the target device; A detection module, used for performing mutual exclusion detection on the target resource of the target driver corresponding to each application request to obtain a detection result; A management module, configured to manage each of the target resources accordingly in the user-mode driver based on the detection result; Among them, the detection result includes a time detection result and a type detection result, and the detection module includes a table building submodule, a time submodule and a type submodule; the table building submodule is used to create a mutually exclusive resource table based on preset resource parameters; the time submodule is used to detect the usage duration of the target resource of the target drive corresponding to each application request based on the mutually exclusive resource table, and obtain the time detection result, wherein the time detection result includes a long occupancy type and a short occupancy type; the type submodule is used to detect the return type of the target resource of the target drive corresponding to each application request based on the mutually exclusive resource table, and obtain the type detection result, wherein the type detection result includes blocking and non-blocking.

9. An electronic device, characterized in that: The electronic device comprises a memory and a processor, wherein the memory stores program instructions, and when the processor runs the program instructions, the steps in the method according to any one of claims 1 to 7 are executed.

10. A computer-readable storage medium, characterized in that: The readable storage medium stores computer program instructions, and when the computer program instructions are executed by a processor, the steps in the method according to any one of claims 1 to 7 are executed.

Images