Device management method and system, electronic device and storage medium

Abstract

Embodiments of the present application provide a device management method and system, an electronic device and a storage medium, which are applied to a compatibility layer including a winebus driver. The method comprises the following steps: the winebus driver listens to the insertion event of all devices in the system; after listening to the insertion event of a target device, first device information is acquired, a physical device object of the target device is created, and a plug and play manager is notified; the first device information comprises a device type; the plug and play manager acquires a first device identifier of the target device, and loads a first function driver according to the first device identifier; the first device identifier comprises a first hardware identifier and a first compatibility identifier; the first compatibility identifier is generated according to the device type; and the first function driver creates a first function device object, and appends the first function device object to the physical device object as a child node. The present application can solve the problems of resource competition and device identification error caused by device node conflict.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a device management method, system, electronic device, and storage medium. Background Technology

[0002] Wine is an open-source compatibility layer that allows Windows applications to run on Unix-like systems such as Linux and macOS. Since Windows applications typically rely on specific hardware interaction methods (such as USB devices and input devices), Wine needs to emulate Windows' hardware management mechanisms, including device drivers, I / O (Input / Output) systems, and PnP (Plug and Play) functionality.

[0003] Wine simulates Windows' hardware management mechanism through multiple components. The I / O manager handles application I / O requests (such as file read / write and device operations) and converts them into unified IRPs (I / O Request Packets) for distribution to drivers. The PnP manager collaborates with the bus driver to dynamically handle device insertion and removal, automatically loading matching drivers. The Winebus driver, based on libubuv, listens for non-USB device events, simulating Windows' general-purpose bus; the wineeusb driver, based on libusb, directly manages USB devices, simulating Windows' USB driver stack. These components together construct a virtual device tree and store device status information in the registry, achieving unified hardware management.

[0004] Although Wine implements basic device management functions, some problems still exist. For example, the winebus driver and wineeusb driver have overlapping functions when detecting some devices. The former captures devices through system events, while the latter directly accesses the USB interface. This may result in the same device being registered repeatedly, leading to device node conflicts and causing resource contention and device identification errors. Summary of the Invention

[0005] In view of the above problems, this application proposes an embodiment to provide a device management method that overcomes or at least partially solves the above problems. It can solve problems such as resource contention caused by device node conflicts in Wine and device identification errors, and can realize extended support for more types of devices, thereby improving the system's flexibility and operating efficiency.

[0006] Accordingly, embodiments of this application also provide a device management system, an electronic device, and a storage medium to ensure the implementation and application of the above methods.

[0007] In a first aspect, embodiments of this application disclose a device management method applied to the compatibility layer Wine in a Linux system, wherein Wine runs a Winebus driver, and the method includes:

[0008] The Winebus driver listens for insertion events of all devices in the system; these devices include both USB and non-USB devices.

[0009] When the Winebus driver detects an insertion event of a target device, it obtains the first device information of the target device, creates a physical device object of the target device, and notifies the Plug and Play Manager; the first device information includes the device type.

[0010] The Plug and Play Manager obtains a first device identifier of the target device and loads a first function driver of the target device based on the first device identifier; the first device identifier includes a first hardware identifier and a first compatibility identifier; the first compatibility identifier is generated based on the device type;

[0011] The first function driver creates a first function device object for the target device and attaches the first function device object as a child node to the physical device object.

[0012] Secondly, embodiments of this application disclose a device management system applied to the Wine compatibility layer in a Linux system, wherein Wine runs a Winebus driver and a plug-and-play manager, wherein:

[0013] The Winebus driver is used to listen for insertion events of all devices in the system. When an insertion event of a target device is detected, it obtains the first device information of the target device, creates a physical device object of the target device, and notifies the Plug and Play Manager. All devices include USB devices and non-USB devices. The first device information includes the device type.

[0014] The plug-and-play manager is used to obtain a first device identifier of the target device and load a first function driver of the target device according to the first device identifier; the first device identifier includes a first hardware identifier and a first compatibility identifier; the first compatibility identifier is generated according to the device type;

[0015] The first function driver is used to create a first function device object of the target device and attach the first function device object as a child node to the physical device object.

[0016] Thirdly, embodiments of this application disclose an electronic device, including: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; the memory is used to store at least one executable instruction, which causes the processor to perform the steps of any of the aforementioned device management methods.

[0017] Fourthly, embodiments of this application disclose a readable storage medium storing a program or instructions, which, when executed by a processor, can implement any of the device management methods described in the embodiments of this application.

[0018] The device management method, system, electronic device, and storage medium provided in this application have the following advantages:

[0019] This application provides a device management method based on driver layering optimization, improving the processing logic of the Winebus driver, Winebus driver, and Plug and Play Manager. It uses only the Winebus driver to uniformly listen for insertion events of all devices in the system, avoiding duplicate registration of the same device. Upon detecting an insertion event of a target device, the Winebus driver creates a physical device object for that target device. Furthermore, this application adds the target device's device type to the first compatibility identifier of the target device, allowing the Plug and Play Manager to dynamically load the corresponding first functional driver based on the device type. For example, for non-USB devices (such as HID devices), the first functional driver for HID devices can be loaded based on the device type. For USB devices, the first functional driver for USB devices, such as the Winebus driver, can be loaded based on the device type. The first functional driver creates a first functional device object for the target device and attaches this first functional device object as a child node to the physical device object, thereby obtaining the device stack of the target device. Device operations can be performed on the target device based on this device stack. This application's embodiments can solve problems such as resource contention and device identification errors caused by device node conflicts in Wine, and can achieve extended support for more types of devices, improving system flexibility and operating efficiency. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating the steps of an embodiment of the device management method of this application;

[0021] Figure 2 This is a schematic diagram of the unified listening device and the device supporting extended types in this application;

[0022] Figure 3 A schematic diagram of the driving relationship in the embodiments of this application;

[0023] Figure 4 This is a structural block diagram of an embodiment of the equipment management system of this application;

[0024] Figure 5 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0025] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0026] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and are not limited in number; for example, a first object can be one or more. Furthermore, the term "and / or" in the specification and claims is used to describe the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0027] First, the key terms involved in this application will be explained.

[0028] Wine is an open-source compatibility layer that allows Windows applications to run on Unix-like systems such as Linux and macOS.

[0029] I / O (Input / Output) refers to the input and output of data between internal memory and external memory or other peripheral devices.

[0030] I / O devices: These include various external devices such as SD cards, USB flash drives, external hard drives, keyboards, monitors, printers, etc. These devices exchange data with the computer through I / O interfaces.

[0031] I / O operations refer to the data transmission process between a computer and external devices.

[0032] PnP (Plug and Play) is a computer technology that allows external devices or hardware to be automatically recognized, configured, and used when connected to a computer without the need for manual driver installation or other complex settings.

[0033] IRP (I / O Request Packet): A data structure that encapsulates I / O requests, containing information such as the request type (e.g., read / write / control) and buffer pointers. When an upper-layer application needs to access an underlying input / output device, it issues an I / O request. The system converts the I / O request into an IRP, and different IRPs trigger the corresponding dispatch function in the I / O device driver.

[0034] The I / O Manager is the core of the entire I / O system, managing all I / O requests (such as reading and writing files, device operations) and coordinating communication between user mode and kernel mode. The I / O Manager converts received I / O requests (usually from applications) into IRPs and passes them to the driver stack for processing.

[0035] PnP Manager (Plug and Play Manager): A core component of the operating system kernel, responsible for the automated management of hardware device detection, enumeration, driver loading, resource configuration, and power management, ensuring that the device can be correctly recognized and operated by the system when plugged in.

[0036] PDO (Physical Device Object): A device object created by the bus driver, representing a physical hardware device connected to the bus. The PDO is the lowest-level node in the device stack, responsible for describing the device's physical attributes and connectivity.

[0037] FDO (Functional Device Object): A device object created by a function driver, representing the logical function implementation of the device. FDOs reside at the upper level of the device stack and are responsible for handling the device's business logic (such as data transmission and control commands).

[0038] Device stack: A hierarchical structure consisting of multiple device objects, including PDOs (Physical Device Objects) and FDOs (Functional Device Objects), representing the complete I / O processing chain of a physical or virtual device.

[0039] Driver stack: A hierarchical structure consisting of multiple drivers, including bus drivers and function drivers, each responsible for handling I / O requests at a specific level.

[0040] The winebus driver is a Windows HID (Human Interface Device) bus kernel emulation driver implemented by Wine (corresponding to winebus.sys). It is used to emulate the Windows HID bus architecture on non-Windows host systems (such as Linux / macOS) and provide compatibility support for non-USB input devices (such as keyboards, mice, game controllers, etc.) on non-Windows host systems.

[0041] The wineusb driver is a Windows USB device stack kernel emulation driver implemented by Wine (corresponding to wineusb.sys). It is used to emulate the Windows USB driver stack on non-Windows host systems, enabling non-Windows host systems to support the enumeration, configuration, and data transfer of USB devices (such as USB flash drives, USB cameras, etc.).

[0042] libudev is a user-space device management library provided by the Linux system. It serves as the programming interface for the udev device manager, used to dynamically monitor device nodes, query device attributes, and respond to hot-plug events. The winebus driver can detect non-USB input devices through libudev.

[0043] libusb is a cross-platform user-space USB device access library that provides a standardized interface for direct control of USB devices without relying on operating system kernel drivers. The wineusb driver can use libusb to enumerate and communicate with USB devices.

[0044] Figure 1 This illustration shows a flowchart of an embodiment of a device management method according to this application. The method can be applied to the compatibility layer Wine in a Linux system, where Wine runs a Winebus driver. The method may include the following steps:

[0045] Step 101: The Winebus driver listens for insertion events of all devices in the system; all devices include USB devices and non-USB devices.

[0046] Step 102: When the Winebus driver detects the insertion event of the target device, it obtains the first device information of the target device, creates a physical device object of the target device, and notifies the Plug and Play Manager; the first device information includes the device type.

[0047] Step 103: The Plug and Play Manager obtains the first device identifier of the target device and loads the first function driver of the target device according to the first device identifier; the first device identifier includes a first hardware identifier and a first compatibility identifier; the first compatibility identifier is generated according to the device type;

[0048] Step 104: The first function driver creates a first function device object for the target device and attaches the first function device object as a child node to the physical device object.

[0049] The device management method provided in this application can be applied to electronic devices based on the Linux operating system. These electronic devices may include, but are not limited to, any of the following: servers, smartphones, voice recorders, tablets, e-book readers, MP3 (Moving Picture Experts Group Audio Layer III) players, MP4 (Moving Picture Experts Group Audio Layer IV) players, laptops, in-vehicle computers, desktop computers, set-top boxes, smart TVs, wearable devices, etc.

[0050] This application does not limit the type of Linux operating system. For example, the Linux operating system may include, but is not limited to, any one of Debian, Ubuntu, CentOS (Community Enterprise Operating System), UOS (Tongxin Desktop Operating System), Kylin Operating System, Fangde Operating System, etc.

[0051] This application provides a device management method based on driver layering optimization. By improving the processing logic of the Winebus driver, Winebus driver, and Plug and Play Manager, it solves problems such as resource contention and device identification errors caused by device node conflicts in Wine. This enables unified detection of device insertion events in Wine through the Winebus driver and dynamic loading of corresponding functional drivers according to device type. On the basis of solving device node conflicts, it can realize extended support for more types of devices, improving the system's flexibility and operating efficiency.

[0052] The Linux system runs a compatibility layer called Wine, which can run Windows applications. Wine contains a Winebus driver. The Winebus driver can monitor insertion events of non-USB devices (such as HID devices) through a device event monitor (such as a udev monitor). This application adds a target device type to the filtering rules of the device event monitor (such as a udev monitor) used by the Winebus driver, so that the Winebus driver can monitor insertion events of the target device type through the udev monitor. The target device type can include both USB and non-USB device types. Furthermore, the target device type can be set according to the actual scenario, thereby enabling the Winebus driver to monitor insertion events of all devices in the system through the udev monitor; all devices include both USB and non-USB devices. Non-USB devices can be any type of device other than USB devices, such as HID devices, PCI devices, and custom extended type devices. Custom extended type devices refer to other types of devices that are not currently extended.

[0053] The udev monitor (i.e., udev_monitor) is a specific object in libuev used to listen for device events. Winebus creates udev monitors through libuev, which can listen for device plug-in and unplug events (insertion and removal).

[0054] This application does not limit the specific devices included in USB devices and non-USB devices. For example, the USB devices include, but are not limited to: storage devices, such as USB flash drives, USB external hard drives, card readers, etc.; input devices, such as USB keyboards, USB mice, USB game controllers, USB drawing tablets, etc.; audio / video devices, such as USB webcams, USB microphones, USB sound cards, USB headphones, etc.; and printing / scanning devices, such as USB printers, USB scanners, etc. The non-USB devices include, but are not limited to, HID devices and PCI (Peripheral Component Interconnect) devices.

[0055] Device drivers in the system are divided into bus drivers and function drivers. Bus drivers are responsible for managing device insertion and removal events and allocating resources for the device. Function drivers implement the core functions of the device.

[0056] This application separates and optimizes the functions of the Winebus driver and the Wineeusb driver in Wine, so that the Winebus driver can uniformly manage the insertion and removal events of all devices, update the virtual state of the devices, and manage the life cycle of the devices; the Wineeusb driver is only responsible for the communication of USB devices.

[0057] The functional improvements to the Winebus driver in this application are as follows: It provides Wine with a unique device monitoring interface, responsible for listening to plug-in and unplug events of various types of devices, and dynamically loading different functional drivers according to the device type. The functional improvements to the Winebus driver are as follows: It is loaded as a functional driver for USB devices, providing operation of USB devices, allowing applications to communicate with USB devices, and interact with USB-HID devices, USB-Storage, or other USB devices.

[0058] In one optional embodiment of this application, the method may further include:

[0059] Disable the function of the wineeusb driver in Wine to listen for device plug-in / plug-out events, while retaining the data transmission function of the wineeusb driver.

[0060] This application disables the function of the winebus driver to listen for device plug-in and unplug events through libusb. All device plug-in and unplug events are listened to uniformly through the winebus driver to ensure that there is only one listening entry point for device plug-in and unplug events.

[0061] Furthermore, this application only disables the function of the wineeusb driver in Wine to listen for device plug-in / plug-out events, while retaining the data transmission function of the wineeusb driver. Therefore, the wineeusb driver focuses solely on communication and data transmission with USB devices. In addition, retaining the data transmission function of the wineeusb driver allows it to obtain USB device descriptor information, such as interface information, configuration information, and endpoint descriptors, through libusb. Since USB device descriptor information cannot be obtained through libudev, it can still be obtained through libusb.

[0062] The timing of using USB device descriptor information depends on the application's operational needs. For example, an application needs to use the endpoint descriptor information of a USB storage device when it needs to write data to it.

[0063] In this embodiment, the Winebus driver is Wine's bus management driver, responsible for handling all device insertion and removal events and maintaining the device tree. Specifically, the Winebus driver listens for all device insertion events through the Linux system's udev monitor, registers devices through the Plug and Play Manager, and ensures the generation of unique device nodes, thereby managing the device's lifecycle and state. When the Winebus driver detects a target device's insertion event, it obtains the target device's first device information, creates the target device's Physical Device Object (PDO), and notifies the Plug and Play Manager; the first device information includes the device type. Further, the first device information may also include other device-related information such as the target device's Vendor ID (VID) and Product ID (PID). The Winebus driver writes the obtained first device information into the target device's PDO's device extension structure. The device extension structure refers to an additional management data structure for the device at the operating system or driver level, created by the operating system or driver during device initialization and changing throughout the device's lifecycle.

[0064] As a bus driver, the Winebus driver creates a Physical Device Object (PDO) for the target device upon detecting its insertion and passes this PDO to the Plug and Play Manager, notifying the Plug and Play Manager to update the device relationships. The Plug and Play Manager can obtain the first device identifier of the target device based on the PDO and load the first function driver for the target device according to the first device identifier. The first device identifier includes a first hardware identifier and a first compatibility identifier; the first compatibility identifier is generated based on the device type.

[0065] The Hardware Identifier (HardwareID) and Compatible Identifier (CompatibleID) are identification information used by the Plug and Play Manager to match the functional drivers of devices. The Hardware Identifier (HardwareID) is a unique identifier for each device, used to accurately match the functional driver, ensuring a one-to-one binding between the device and the driver. The Compatible Identifier (CompatibleID) identifies the general category of the device, used to match general functional drivers, allowing devices of the same type to use the same functional driver. When multiple functional drivers are matched, a priority mechanism can be used to select the best one.

[0066] In practice, the Plug and Play Manager can obtain device identifiers by calling preset functions. Device identifiers include a Hardware Identifier (HardwareID) and a Compatible Identifier (CompatibleID). Device identifiers are typically generated from a fixed string. For the Compatible Identifier (CompatibleID), different device types have different fixed strings, while devices of the same type have the same fixed string.

[0067] In this embodiment, the device identifier obtained by the Plug and Play Manager calling a preset function is referred to as the first device identifier, which includes a first hardware identifier and a first compatibility identifier. This application modifies the function used to obtain the device identifier so that the first compatibility identifier is dynamically generated based on the device type.

[0068] Further, obtaining the first device identifier of the target device may include:

[0069] The first function is called to obtain the hardware identifier of the target device; the first function concatenates the manufacturer identifier and product identifier of the target device with a preset fixed string to obtain the hardware identifier of the target device;

[0070] The second function is called to obtain the compatibility identifier of the target device; the second function concatenates the device type of the target device with the preset fixed string to obtain the compatibility identifier of the target device.

[0071] The first and second functions can be defined and implemented in the driver (such as the Winebus driver), and the Plug and Play Manager obtains the device identifier by calling its own built-in functions (such as the get_device_id function).

[0072] For example, the get_device_id function is represented as follows: get_device_id(DEVICE_OBJECT*device, BUS_QUERY_ID_TYPE type, WCHAR**id). This function takes three parameters: the first parameter is a pointer to the target device; the second parameter is a query type parameter, which indicates the type of device identifier to be obtained, such as a hardware identifier or a compatibility identifier; and the third parameter is used to receive the retrieved device identifier string.

[0073] In practice, when a device identifier is needed, the Plug and Play Manager calls the preset function `get_device_id`, sending an `IRP_MN_QUERY_ID` (an IRP used to retrieve the device identifier) ​​through this function. This IRP carries a query type parameter (such as the value of the `type` variable). The Winebus driver determines whether to retrieve the HardwareID or the CompatibleID based on the IRP and its query type parameter. For example, if the Plug and Play Manager calls the `get_device_id` function and assigns the query type parameter `BusQueryHardwareIDs`, the Winebus driver receives an IRP with the query type parameter `BusQueryHardwareIDs`, indicating that a hardware identifier is needed. The Winebus driver then calls the first function (such as `get_hardware_ids`), concatenating a fixed string with the target device's Vendor Identifier (VID) and Product Identifier (PID) to obtain the first hardware identifier (HardwareID). If the query type parameter is BusQueryCompatibleIDs, it means that a compatibility identifier needs to be obtained. Then the Winebus driver calls the second function (such as get_compatible_ids), which concatenates the fixed string with the target device's device type (such as bustype) string to obtain the first compatibility identifier (CompatibleID).

[0074] The Plug and Play Manager loads the first function driver of the target device based on the first device identifier (first hardware identifier and first compatibility identifier).

[0075] Specifically, the Plug and Play Manager scans the INF (Installation Information File) files of each function driver in the system, compares the preset fields (such as the mfg_section field) in the INF file with the first device identifier, and if a matching preset field is found, it is determined that a matching first function driver has been found.

[0076] An INF file is a configuration file used to guide driver installation. A feature driver's INF file may contain the following information: a default field `mfg_section` for matching the feature driver; a list of driver files (such as .sys, .dll, etc.); registry configuration information (such as device parameters, service registration information, etc.); and installation instructions (such as file copying, service startup, etc.).

[0077] In practice, the INF file may contain multiple preset fields for matching function drivers, such as a preset field for matching the Hardware ID and a preset field for matching the Compatible ID. The Plug and Play Manager compares the target device's Hardware ID and Compatible ID with the preset fields in the INF file. If any one of these preset fields matches, the first matching function driver is found.

[0078] Furthermore, during the matching process, the first hardware identifier is matched first. If no matching first functional driver is found, the first compatible identifier is matched. If no matching first functional driver is found, an error message is displayed indicating that no functional driver can be loaded.

[0079] In related technologies, the Winebus driver only supports listening to HID device insertion events, making it difficult to flexibly support new hardware; furthermore, the driver's modular design is insufficient, requiring code modifications when expanding to new devices, resulting in high adaptation costs. These issues limit Wine's compatibility and stability in complex hardware environments.

[0080] This application expands the device types monitored by the Winebus driver. Besides monitoring HID device insertion events, it can also monitor insertion events of USB devices, PCI devices, and custom extended type devices. Furthermore, this application modifies the Winebus-provided compatibility identifier from a fixed string to a dynamic concatenation of a fixed string and the device type. Therefore, for USB devices, the first compatibility identifier obtained by the Plug and Play Manager includes the USB device's device type. When the Plug and Play Manager cannot find a corresponding function driver based on the first hardware identifier of the USB device, it can find the corresponding function driver based on the first compatibility identifier. Further, when the target device is a USB device, the matching first function driver is the Winebus driver.

[0081] When the target device is a non-USB device (such as an HID device), the first compatibility identifier of the HID device obtained by the Plug and Play Manager is appended with the device type of the HID device. The Plug and Play Manager first matches the first function driver based on the first hardware identifier of the HID device. If a match is found, it is loaded; if no match is found, it matches the first function driver based on the first compatibility identifier of the HID device. If a match is found, it is loaded; if no match is found, it indicates that no function driver can be loaded.

[0082] Furthermore, this application can achieve expanded support for more types of devices. For example, in addition to USB devices, the Winebus driver can also monitor PCI devices and custom extended type devices, etc.

[0083] This application adds a target device type to the filtering rules of the device event monitor used by the Winebus driver, so that the Winebus driver can listen for insertion events of the target device type through the device event monitor; the target device type may include USB device type, PCI device type and custom extended device type.

[0084] The modified Winebus driver processing flow in this application is as follows: The operating system calls the driver entry function DriverEntry to start the Winebus driver and complete its initialization. The initialization process includes calls to the functions DriverEntry and AddDevice. DriverEntry is the initial entry point for the Winebus driver, called by the operating system during driver loading. AddDevice is the device addition function, called when the PnP manager (Plug and Play Manager) detects a new device. After initialization, during device startup, a udev monitor (udev_monitor) can be created and filtering rules can be set, allowing the Winebus driver to monitor and manage target devices, including USB and non-USB devices. The Winebus driver uses udev_monitor to uniformly monitor device events, such as insertion or removal events. If the Winebus driver detects an insertion event, it calls the device addition function udev_add_device to register the device to Wine's virtual bus. This application extends the filtering rules of udev_monitor, so that the udev_add_device function can add not only HID devices, but also USB devices, PCI devices, and custom extended devices.

[0085] Specifically, the filtering rules of the udev monitor (udev_monitor) are as follows: Subsystems on Linux are filtered using device filtering functions (such as the udev_monitor_filter_add_match_subsystem_devtype function). These subsystems can include two dimensions: device type and interface type. The device type corresponds to a specific physical device, or hardware device type. The interface type corresponds to an abstract function, or functional interface type. The functional interface type is defined by the Linux system and is not the actual interface of a physical device, but rather an abstract functional interface. In practice, the filtering rules can be configured to filter subsystems corresponding to different device types (hardware device types) or different interface types (functional interface types), as needed. For example, the filtering rules include: udev_monitor_filter_add_match_subsystem_devtype(monitor,"hidraw",NULL); udev_monitor_filter_add_match_subsystem_devtype(monitor,"input",NULL).

[0086] The above filtering rules are used to filter subsystems of HID device types, specifically, to filter the hidraw and input functional interfaces of HID device types. HID devices include two functional interfaces: hidraw and input. The hidraw interface is used to handle raw data communication, and the input interface is used to handle standardized input events.

[0087] Furthermore, this application adds a subsystem for filtering USB device types, specifically as follows: udev_monitor_filter_add_match_subsystem_devtype(monitor,"usb",NULL);

[0088] In addition, a subsystem for filtering PCI device types is added, as follows: udev_monitor_filter_add_match_subsystem_devtype(monitor,"pci",NULL).

[0089] Furthermore, this application can also add a subsystem for filtering custom device types. For example, assuming a custom extended type device, such as a "sound" type device, needs to be added, a subsystem for filtering "sound" device types is added to the filtering rules of the udev monitor (udev_monitor), and the CompatibleID of this type of device is set in the preset field mfg_section of the function driver INF file for "sound" type devices. Thus, the Winebus driver can listen for the insertion event of this "sound" type device and load the corresponding function driver according to the "sound" type.

[0090] Reference Figure 2 This diagram illustrates the structure of the unified listening device and its support for extended device types as described in this application. Figure 2 As shown, the modified Winebus driver in this application is compatible with the management of multiple types of devices and provides unified event distribution.

[0091] like Figure 2 As shown, this application does not limit the type of target device. Through the embodiments of this application, support for multiple types of devices can be extended, such as PCI devices, USB-HID devices, USB-CCID (USB smart card interface devices) and other compatible devices.

[0092] After the first functional driver is successfully loaded, it creates a first functional device object (FDO) for the target device and attaches it as a child node to the physical device object (PDO), thus forming a device stack for the target device, represented as follows: Physical Device Object (PDO) -> First Functional Device Object (FDO). The device stack consists of physical device objects and functional device objects, providing the implementation foundation for performing device operations. The physical device object (PDO) is created by the bus driver (such as the Winebus driver), directly interacts with the hardware, and is responsible for the underlying protocol. The functional device object (FDO) is created by the functional driver and implements the specific functions of the device.

[0093] Taking a USB device as an example, after the Winebus driver detects a USB device insertion event, it creates a Physical Device Object (PDO). Then, the Winebus driver interacts with the Plug and Play Manager to load the USB device's functional driver (i.e., the Winebus driver). The Plug and Play Manager's loading process calls the AddDevice interface in the Winebus driver, which in turn calls the driver_add_device function to create a first functional device object (FDO). Next, the Winebus driver calls the API function IoAttachDeviceToDeviceStack(FDO, PDO) to attach the PDO created by the Winebus driver as the parent node and the first functional device object (FDO) created by the Winebus driver as the child node, forming a device stack. This device stack provides the foundation for subsequent device operations on the USB device.

[0094] This application uses a Winebus driver to interface with various devices on a Linux system, making it the sole device monitoring module. The Winebus driver interacts with the Plug and Play Manager, dynamically loading function drivers for different types of devices (such as USB devices, HID devices, etc.) based on the device type.

[0095] This application disables the Winebus driver's function of listening to device plug-in / plug-out events while retaining its data transmission function. The Winebus driver is loaded as a functional driver for USB devices. Thus, the parallel relationship between the Winebus driver and the Winebus driver is transformed into a vertical relationship, with the Winebus driver unifying the listening for device plug-in / plug-out events. When the target device is a USB device, the Winebus driver is loaded as the target device's functional driver. Because this application disables the Winebus driver's function of listening to device plug-in / plug-out events but retains its data transmission function, the Winebus driver can obtain USB device-specific information through libusb (when libusb cannot obtain it), and thus can implement specific USB device communication logic through the Winebus driver.

[0096] When the target device is a non-USB device (such as an HID device), Winebus, as the bus driver, listens for the insertion of the HID device and loads the HID device's functional driver (such as HidClass.sys / winehid.sys) by interacting with the Plug and Play Manager. The communication logic of the HID device is then implemented through HidClass.sys / winehid.sys.

[0097] This application uses a Winebus driver to uniformly detect device insertion events in Wine and dynamically loads the corresponding function driver according to the device type. This can solve problems such as resource contention and device identification errors caused by device node conflicts in Wine, and can also achieve extended support for more types of devices, improving the system's flexibility and operating efficiency.

[0098] In one optional embodiment of this application, the target device is a USB device, and the first function driver is a Windowsb driver; the method may further include:

[0099] Step S11: The wineeusb driver obtains the second device information of the target device, creates a sub-physical device object of the target device, and notifies the plug-and-play manager; the second device information includes the interface type;

[0100] Step S12: The Plug and Play Manager obtains the second device identifier of the target device and loads the second function driver of the target device according to the second device identifier; the second device identifier includes a second hardware identifier and a second compatibility identifier; the second compatibility identifier is generated according to the interface type;

[0101] Step S13: The second function driver creates a second function device object for the target device and attaches the second function device object as a child node to the sub-physical device object.

[0102] It should be noted that the first function driver is obtained based on the device type matching of the target device, which reflects the major category of physical devices (such as HID device type, USB device type, etc.). The second function driver is obtained based on the interface type matching of the target device (such as USB device), which refers to the interface type of the USB device, which is the interface type classified according to the function of the USB device, reflecting the specific purpose of the USB device (such as scanner, keyboard, gamepad, etc.).

[0103] In this embodiment, the Winebus driver acts as the bus driver that listens for all device insertion events, while the Wineusb driver serves as both the Winebus function driver and the USB device bus driver. Therefore, it is necessary to create a physical device object for the USB device, i.e., to create a child physical device object (Child_PDO). The Wineusb driver interacts with the Plug and Play Manager as the USB device bus driver to load a second function driver that matches the specific interface type of the USB device.

[0104] When the Winebus driver, acting as the bus driver, detects a device insertion, it notifies the Plug and Play Manager to update the Winebus device relationships. When the Winebus driver, acting as the bus driver for a USB device, creates a child physical device object (Child_PDO) for the USB device, it is equivalent to virtually "inserting a device" into the system, and therefore also needs to notify the Plug and Play Manager to update the Winebus device relationships.

[0105] Taking a USB scanner as an example, the device type (physical device category) of the USB scanner is USB device type, and the interface type (specific purpose) is USB scanner type (USBSCAN).

[0106] When the USB scanner is plugged in, the Winebus driver listens for the insertion event of the target device (USB scanner) through libuev, obtains the first device information, creates a Physical Device Object (PDO), writes the obtained first device information into the device extension of the Physical Device Object (PDO), and sends the Physical Device Object (PDO) to the Plug and Play Manager to notify the Plug and Play Manager to update the device relationship.

[0107] The first device information is obtained by the Winebus driver through libuev. The first device information may include device node path, VID, PID, device type and other device-related information.

[0108] The Plug and Play Manager can obtain the device identifier by sending an IRP request (IRP_MN_QUERY_ID) to the Physical Device Object (PDO). The driver (Winebus driver) containing the PDO determines whether to call a first function or a second function based on the query type parameter carried in the IRP request. The first and second functions can obtain the first device information recorded in the device extension of the PDO, and then generate a first hardware identifier and a first compatibility identifier, respectively.

[0109] The Plug and Play Manager can find a matching first function driver based on the acquired first hardware identifier and first compatibility identifier. Since the target device is a USB device, the matched first function driver is the Windowsb driver, and the Windowsb driver is then loaded.

[0110] The first function driver (such as the wineeusb driver) creates a first function device object for the target device and attaches the first function device object as a child node to the physical device object, forming a device stack. This device stack includes physical device objects (PDOs) and first function device objects (FDOs).

[0111] The first function driver (wineusb driver) acts as the bus driver for the USB device. It obtains the second device information of the target device (USB scanner), creates a child physical device object (Child_PDO) for the target device, writes the second device information into the device extension of the child physical device object (Child_PDO), and sends the child physical device object (Child_PDO) to the Plug and Play Manager to notify the Plug and Play Manager to update the device relationship.

[0112] The second device information is obtained by the wineeusb driver through libusb. This second device information may include USB device descriptor information such as the USB device's interface type and endpoint information. The USB device's interface type includes, but is not limited to, USB storage, USB CCID (USB smart card interface device), and USBSCAN (USB scanner).

[0113] The Plug and Play Manager obtains the device identifier by sending an IRP request (IRP_MN_QUERY_ID) to the child physical device object (Child_PDO). The driver (wineusb driver) containing the child physical device object (Child_PDO) determines whether to call the first or second function based on the query type parameter carried in the IRP request. The first and second functions can obtain the second device information recorded in the device extension of the child physical device object (Child_PDO), and then generate the second hardware identifier and the second compatibility identifier, respectively.

[0114] It should be noted that the first hardware identifier is obtained by concatenating the target device's VID and PID with a preset fixed string (referred to here as the first fixed string). The first compatibility identifier is obtained by concatenating the target device's device type with the first fixed string. The second hardware identifier is obtained by concatenating the target device's VID and PID with a preset fixed string (referred to here as the second fixed string). The second compatibility identifier is generated based on the target device's interface type. For example, the second compatibility identifier can be obtained by concatenating the target field representing the target device's interface type with the second fixed string. Since the target device (USB scanner) is identified as a USB device type at the Winebus driver layer and as a USB scanner type at the Winebus driver layer, the two types are different, therefore the first fixed string and the second fixed string are different.

[0115] The target field can be a key field in the USB device descriptor, used to identify the device's general functions and behavioral specifications. USB device descriptors include various types such as device descriptors, configuration descriptors, and endpoint descriptors. For example, the target field includes, but is not limited to, the device's Class, Subclass, and Protocol. The target field can be obtained through libusb.

[0116] The Plug and Play Manager searches for a matching second function driver based on the acquired second hardware identifier and second compatibility identifier. Since the target device's interface type is USBSCAN (USB scanner), the matched second function driver is wineusbscan.sys, and wineusbscan.sys is then loaded.

[0117] The second function driver (such as wineusbscan.sys) creates a second function device object (FDO) for the target device (USB scanner) and attaches the second function device object as a child node to the sub-physical device object.

[0118] Reference Figure 3 The diagram illustrates the driving relationship in an embodiment of this application. Figure 3 As shown, this application transforms the winebus driver and wineeusb driver from a parallel relationship to a vertical (stack) relationship. The winebus driver is the only interface for listening to device plug-in / plug-out events, the wineeusb driver is the function driver for USB devices, and HidClass.sys / winehid.sys is the function driver for HID devices.

[0119] like Figure 3 As shown, ①, ②, and ③ respectively represent the process by which the Plug and Play Manager writes device and driver information to the registry when it detects a change in a Winebus, WineESB, or HID device. Steps 1 to 5 represent the following steps:

[0120] 1. Load the Winebus driver after system initialization;

[0121] 2. The Winebus driver detects USB device insertion events via Librav;

[0122] 3. Load the first functional driver for the USB device, wineeusb;

[0123] 4. The wineusb driver obtains USB device descriptor information through libusb;

[0124] 5. Load the second function driver for the interface according to the interface type. For example, if the interface type is HID, load the function driver hidclass.sys / winehid.sys for HID devices; if the interface type is USBSCAN, load the function driver wineusbscan.sys for USB scanners.

[0125] This application transforms the parallel relationship between the Winebus driver and the Winebus driver into a vertical (stack) relationship, thereby realizing the driver hierarchy and calling relationship, unifying the parent-child relationship of device nodes on the same device, and avoiding device node duplication and conflicts.

[0126] For non-USB devices, such as HID devices, this application creates the following device stack for HID devices: Physical Device Object (PDO) -> First Functional Device Object (FDO). The First Functional Device Object (FDO) can receive Input / Output Request packets (IRPs). These IRPs are generated by the system's Input / Output Manager when it receives an input / output request from an application for the target device. The IRP carries a request type, which can be any of the following: read, write, control, etc. The First Functional Device Object decides whether to directly process the IRP or forward it to the Physical Device Object for processing based on the request type.

[0127] In one optional embodiment of this application, the method may further include:

[0128] Step S21: The second functional device object receives an input / output request packet. The input / output request packet is generated by the input / output manager in the system when it receives an input / output request from the application for the target device. The input / output request packet carries the request type.

[0129] Step S22: The second functional device object decides, based on the request type, whether to directly process the input / output request packet or to forward the input / output request packet to the sub-physical device object for processing.

[0130] For USB devices, this application creates two device stacks for the USB device as follows: First device stack: Physical Device Object (PDO) -> First Functional Device Object (FDO, created by the wineeusb driver); Second device stack: Child Physical Device Object (Child_PDO) -> Second Functional Device Object (FDO, created by the specific device function driver).

[0131] The two device stacks described above enable various device operations on a USB device from an application. For example, low-level operations, such as read or write operations, can be performed using the second device stack. Higher-level operations, such as reading device attribute information, require passing the information from the second device stack to the first device stack. The device attribute information refers to udev device attributes, such as the device model name (ID_MODEL) and device serial number (ID_SERIAL). udev is a system in Linux used to manage device nodes, allowing userspace programs to obtain device information and create device nodes based on these attributes. In practice, the second device stack is called first for processing. If the request type determines that Winebus driver processing is required, such as a request to read udev device attribute information, the first device stack is then called for processing.

[0132] The second functional device object (FDO) receives input / output request packets (IRPs), which are generated by the system's input / output manager when it receives an input / output request from an application for the target device. The IRPs carry a request type, which can be any of the following: read, write, control, etc. The second functional device object (FDO) decides, based on the request type, whether to directly process the IRP or forward it to the child physical device object (Child_PDO) for processing.

[0133] It should be noted that the IRP is forwarded from the top of the stack downwards. In this embodiment of the application, when the second functional device object (FDO) is at the top of the stack, the IRP first reaches the second functional device object (FDO), and then it is determined whether to continue forwarding downwards according to the request type of the IRP.

[0134] In practice, when a filter driver exists and is located at the top of the stack, the IRP first reaches the filter driver and is then forwarded down to the Functional Device Object (FDO). A filter driver is a special type of driver that is inserted into the device stack to intercept and process I / O requests passed to the target device.

[0135] In one optional embodiment of this application, the method may further include:

[0136] If the sub-physical device object receives the input / output request packet and determines that the request type includes any one of control transmission, bulk transmission, and interrupt transmission, then the sub-physical device object directly processes the input / output request packet.

[0137] If the request type is determined to be reading device attribute information, the sub-physical device object forwards the input / output request packet to the first functional device object for processing.

[0138] Furthermore, if the sub-physical device object receives the input / output request packet, it decides, based on the request type, to either directly process the input / output request packet or forward it to the first functional device object (FDO) of the target device for processing. The first functional device object then decides, based on the request type, to either directly process the input / output request packet or forward it to the physical device object (PDO) for processing.

[0139] Although the Child Physical Device Object (Child_PDO) and the First Functional Device Object (FDO) belong to different device stacks, they are both created by the same driver, wineeusb, and therefore can communicate with each other. When the Child Physical Device Object (Child_PDO) determines that the input / output request packet (IRP) needs to be forwarded to the next level of processing based on the request type carried by the received IRP, it can forward the IRP to the First Functional Device Object (FDO) for further processing.

[0140] Taking a USB scanner as an example, after establishing the two device stacks of the USB scanner through the above steps, when the application needs to transmit data with the USB scanner, the application triggers an input / output request for the USB scanner. The input / output manager in the system converts the input / output request into an IRP and first sends it to the second function device object (FDO) created by the second function driver (wineusbscan.sys) for processing. The second function device object (FDO) determines whether further processing is required based on the request type, and then forwards it to the child physical device object (Child_PDO) created by the first function driver (wineusb) for processing. The child physical device object (Child_PDO) determines whether further processing is required based on the request type, and then forwards it to the first function device object (FDO) created by the first function driver (wineusb) for processing. The first function device object (FDO) determines whether further processing is required based on the request type, and then forwards it to the physical device object (PDO) created by the bus driver (winebus) for processing.

[0141] The wineusb driver, based on libusb, can provide the following functions: control transfer (libusb_control_transfer), bulk transfer (libusb_bulk_transfer), interrupt transfer (libusb_interrupt_transfer), etc., allowing Windows applications to perform low-level read / write operations on USB devices.

[0142] For high-level device operations such as reading udev device attribute information, the Winebus driver is required for processing. Therefore, when the sub-physical device object receives the input / output request packet, if it determines that the request type is to read udev device attribute information, the sub-physical device object forwards the input / output request packet to the first functional device object created by the Winebus driver for processing. The first functional device object decides whether to process the input / output request packet directly or forward it to the physical device object created by the Winebus driver for processing based on the request type. Since reading udev device attribute information requires processing by the physical device object, the first functional device object forwards the input / output request packet for reading udev device attribute information to the physical device object (PDO) created by the Winebus driver for processing.

[0143] Furthermore, for a USB device, the number of child physical device objects (Child_PDOs) created can be determined based on the number of interfaces of the USB device. The number of interfaces is information in the configuration descriptor of the USB device. For example, if the USB device is a composite device, the same number of child physical device objects can be created based on the number of interfaces of the USB device. For example, if the USB device is a composite device and has 2 interfaces, one interface (e.g., interface0) has an HID interface type, and the other interface (e.g., interface1) has a storage interface type, then two child physical device objects are created: one child physical device object (e.g., Child1_PDO) corresponding to interface0, and the other child physical device object (e.g., Child2_PDO) corresponding to interface1.

[0144] Therefore, for this USB device, the following three device stacks can be created: First device stack: Physical Device Object (PDO) -> First Functional Device Object (FDO, created by the wineeusb driver); Second device stack: Child Physical Device Object (Child1_PDO) -> Second Functional Device Object (FDO, created by the HID type device function driver); Third device stack: Child Physical Device Object (Child2_PDO) -> Second Functional Device Object (FDO, created by the storage type device function driver).

[0145] It's important to note that the IRP processing flow is a top-down forwarding process within the device stack. Taking a USB scanner as an example, if the request type is to read udev device attribute information, the IRP first reaches the top of the second device stack of the USB scanner, namely the second functional device object (FDO) created by the second functional driver (such as the wineeusbscan driver). Then, this second functional device object (FDO) forwards the request to the child physical device object (child_PDO) created by the first functional driver (such as the wineeusb driver). This child physical device object (child_PDO) communicates with the first functional device object (FDO) created by the first functional driver (such as the wineeusb driver) to forward the IRP to the top of the first device stack of the USB scanner, namely the first functional device object (FDO). This first functional device object (FDO) then forwards the request to the physical device object (PDO) created by the bus driver (such as the winebus driver), where the physical device object (PDO) processes the IRP and reads the udev device attribute information.

[0146] For example, for the composite type USB device in the above example, when an application needs to use the HID type function of the USB device, it can call the second function device object (FDO) created by the HID type device function driver. The second function device object (FDO) determines whether to directly process the IRP or forward it further down to the child physical device object (Child1_PDO). When the application needs to use the storage type function of the USB device, it can call the second function device object (FDO) created by the storage type device function driver. The second function device object (FDO) determines whether to directly process the IRP or forward it further down to the child physical device object (Child2_PDO).

[0147] This application optimizes the logic of device monitoring, management, and access in Wine by modifying the hierarchical architecture of the Winebus and WineESS drivers. It clarifies the division of responsibilities between the Winebus and WineESS drivers, achieving a modular, flexible, and efficient device management method. The responsibility for listening to device plug-in / plug-out events is centralized in the Winebus driver, avoiding conflicts between drivers. Dynamically loading function drivers based on device type makes the system more flexible, facilitating the expansion of different types of device drivers and improving compatibility with multiple device types such as PCI, USB-HID, and USB-CCID. Furthermore, when expanding to new device types, this application only requires adding code to filter the new device type, without modifying the driver loading code, reducing expansion costs and improving Wine's compatibility and stability in complex hardware environments. Moreover, this application restructures the driver stack relationship, unifying the driver hierarchy and calling relationships, and unifying the parent-child relationships of device nodes for the same device, avoiding device node duplication and conflicts.

[0148] In summary, this application provides a device management method based on driver layering optimization, improving the processing logic of the Winebus driver, Winebus driver, and Plug and Play Manager. It uses only the Winebus driver to uniformly monitor insertion events of all devices in the system, avoiding duplicate registration of the same device. Upon detecting an insertion event of a target device, the Winebus driver creates a physical device object for that target device. Furthermore, this application adds the target device's device type to the first compatibility identifier of the target device, allowing the Plug and Play Manager to dynamically load the corresponding first functional driver based on the device type. For example, for non-USB devices (such as HID devices), the first functional driver for HID devices can be loaded based on the device type. For USB devices, the first functional driver for USB devices, such as the Winebus driver, can be loaded based on the device type. The first functional driver creates a first functional device object for the target device and attaches this first functional device object as a child node to the physical device object, thereby obtaining the device stack of the target device. Device operations can be performed on the target device based on this device stack. The embodiments of this application can solve problems such as resource contention and device identification errors caused by device node conflicts in Wine, and can also achieve extended support for more types of devices, thereby improving the system's flexibility and operating efficiency.

[0149] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of this application.

[0150] Reference Figure 4 The diagram illustrates a structural block diagram of an embodiment of a device management system according to this application. The system is applied to the Wine compatibility layer within a Linux system. Wine contains a Winebus driver and a plug-and-play manager, wherein:

[0151] The Winebus driver 401 is used to listen for insertion events of all devices in the system. When an insertion event of a target device is detected, it obtains the first device information of the target device, creates a physical device object of the target device, and notifies the Plug and Play Manager. All devices include USB devices and non-USB devices. The first device information includes the device type.

[0152] The plug-and-play manager 402 is used to obtain a first device identifier of the target device and load a first function driver of the target device according to the first device identifier; the first device identifier includes a first hardware identifier and a first compatibility identifier; the first compatibility identifier is generated according to the device type;

[0153] The first function driver 403 is used to create a first function device object of the target device and attach the first function device object as a child node to the physical device object.

[0154] Optionally, the target device is a USB device, and the first function driver is a wineeusb driver;

[0155] The wineeusb driver is used to obtain the second device information of the target device, create a sub-physical device object of the target device, and notify the plug-and-play manager; the second device information includes the interface type;

[0156] The plug-and-play manager is further configured to obtain a second device identifier of the target device and load a second function driver of the target device based on the second device identifier; the second device identifier includes a second hardware identifier and a second compatibility identifier; the second compatibility identifier is generated based on the interface type;

[0157] The second function driver is used to create a second function device object of the target device and attach the second function device object as a child node to the sub-physical device object.

[0158] Optionally, the second functional device object is used to receive input / output request packets and, based on the request type, decide whether to directly process the input / output request packet or forward the input / output request packet to the sub-physical device object for processing; the input / output request packet is generated by the input / output manager in the system when it receives an input / output request from an application for the target device, and the input / output request packet carries the request type.

[0159] Optionally, the sub-physical device object is further configured to receive the input / output request packet. If the request type is determined to include any one of control transmission, bulk transmission, and interrupt transmission, the sub-physical device object directly processes the input / output request packet. If the request type is determined to be reading device attribute information, the sub-physical device object forwards the input / output request packet to the first functional device object for processing.

[0160] Optionally, the first device information may also include a manufacturer identifier and a product identifier;

[0161] The plug-and-play manager is also used to trigger the driver to call the first function to obtain the hardware identifier of the target device; the first function concatenates the manufacturer identifier and product identifier of the target device with a preset fixed string to obtain the hardware identifier of the target device.

[0162] The plug-and-play manager is also used to trigger the driver to call the second function to obtain the compatibility identifier of the target device; the second function concatenates the device type of the target device with the preset fixed string to obtain the compatibility identifier of the target device.

[0163] Optionally, the system further includes:

[0164] The rule setting module is used to add target device types to the filtering rules of the device event monitor used by the Winebus driver, so that the Winebus driver can listen for insertion events of the target device type through the device event monitor; the target device type includes any one of USB device type, HID device type, PCI device type, and custom extended device type.

[0165] Optionally, the system further includes:

[0166] The driver settings module is used to disable the Wineeusb driver's function of listening to device plug-in / plug-out events, while retaining the data transmission function of the Wineeusb driver.

[0167] This application provides a device management system based on driver layering optimization. It improves the processing logic of the Winebus driver, Winebus driver, and Plug and Play manager, uniformly monitoring insertion events of all devices in the system solely through the Winebus driver, avoiding duplicate registration of the same device. Upon detecting an insertion event of a target device, the Winebus driver creates a physical device object for that target device. Furthermore, this application adds the target device's device type to the first compatibility identifier of the target device, allowing the Plug and Play manager to dynamically load the corresponding first functional driver based on the device type. For example, for non-USB devices (such as HID devices), the first functional driver for HID devices can be loaded based on the device type. For USB devices, the first functional driver for USB devices, such as the Winebus driver, can be loaded based on the device type. The first functional driver creates a first functional device object for the target device and attaches this first functional device object as a child node to the physical device object, thereby obtaining the device stack of the target device. Device operations can be performed on the target device based on this device stack. This application's embodiments can solve problems such as resource contention and device identification errors caused by device node conflicts in Wine, and can achieve extended support for more types of devices, improving system flexibility and operating efficiency.

[0168] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0169] Reference Figure 5 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. Figure 5 As shown, the electronic device includes: a processor, a memory, a communication interface, and a communication bus. The processor, the memory, and the communication interface communicate with each other through the communication bus. The memory is used to store at least one executable instruction, which causes the processor to perform the steps of the device management method of the aforementioned embodiment.

[0170] This application provides a non-transitory computer-readable storage medium that, when the instructions in the storage medium are executed by a terminal's program or processor, enables the terminal to perform the steps of the device management method described in the foregoing embodiments.

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

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

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

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

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

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

[0177] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for managing equipment, characterized in that, The method for using Wine, a compatibility layer applied to Linux systems, wherein Wine runs a Winebus driver, includes: Disable the function of the wineeusb driver in Wine to listen for device plug-in / plug-out events, while retaining the data transmission function of the wineeusb driver; The Winebus driver listens for insertion events of all devices in the system; these devices include both USB and non-USB devices. When the Winebus driver detects an insertion event of a target device, it obtains the first device information of the target device, creates a physical device object of the target device, and notifies the Plug and Play Manager; the first device information includes the device type. The Plug and Play Manager obtains a first device identifier of the target device and loads a first function driver of the target device based on the first device identifier; the first device identifier includes a first hardware identifier and a first compatibility identifier; the first compatibility identifier is generated based on the device type; The first function driver creates a first function device object for the target device and attaches the first function device object as a child node to the physical device object; The first device information further includes a manufacturer identifier and a product identifier; obtaining the first device identifier of the target device includes: The first function is called to obtain the hardware identifier of the target device; the first function concatenates the manufacturer identifier and product identifier of the target device with a preset fixed string to obtain the hardware identifier of the target device; The second function is called to obtain the compatibility identifier of the target device; the second function concatenates the device type of the target device with the preset fixed string to obtain the compatibility identifier of the target device.

2. The method according to claim 1, characterized in that, The target device is a USB device, and the first function driver is a Windowsb driver; the method further includes: The wineeusb driver obtains the second device information of the target device, creates a sub-physical device object of the target device, and notifies the plug-and-play manager; the second device information includes the interface type; The Plug and Play Manager obtains the second device identifier of the target device and loads the second function driver of the target device according to the second device identifier; the second device identifier includes a second hardware identifier and a second compatibility identifier; the second compatibility identifier is generated according to the interface type; The second function drives the creation of a second function device object for the target device, and attaches the second function device object as a child node to the sub-physical device object.

3. The method according to claim 2, characterized in that, The method further includes: The second functional device object receives an input / output request packet, which is generated by the input / output manager in the system when it receives an input / output request from an application for the target device. The input / output request packet carries the request type. The second functional device object decides, based on the request type, whether to directly process the input / output request packet or to forward the input / output request packet to the sub-physical device object for processing.

4. The method according to claim 3, characterized in that, The method further includes: If the sub-physical device object receives the input / output request packet and determines that the request type includes any one of control transmission, bulk transmission, and interrupt transmission, then the sub-physical device object directly processes the input / output request packet. If the request type is determined to be reading device attribute information, the sub-physical device object forwards the input / output request packet to the first functional device object for processing.

5. The method according to claim 1, characterized in that, The method further includes: Add a target device type to the filtering rules of the device event monitor used by the Winebus driver, so that the Winebus driver can listen for insertion events of the target device type through the device event monitor; the target device type includes any one of USB device type, HID device type, PCI device type, and custom extended device type.

6. An equipment management system, characterized in that, Wine, a compatibility layer applied to Linux systems, runs a Winebus driver, a plug-and-play manager, and a driver configuration module, among which: The Winebus driver is used to listen for insertion events of all devices in the system. When an insertion event of a target device is detected, it obtains the first device information of the target device, creates a physical device object of the target device, and notifies the Plug and Play Manager. All devices include USB devices and non-USB devices. The first device information includes the device type. The plug-and-play manager is used to obtain a first device identifier of the target device and load a first function driver of the target device according to the first device identifier; the first device identifier includes a first hardware identifier and a first compatibility identifier; the first compatibility identifier is generated according to the device type; The first function driver is used to create a first function device object of the target device and attach the first function device object as a child node to the physical device object; The driver settings module is used to disable the function of the wineeusb driver in Wine to listen for device plug-in / plug-out events, while retaining the data transmission function of the wineeusb driver. The first device information also includes manufacturer identification and product identification; The plug-and-play manager is also used to trigger the driver to call the first function to obtain the hardware identifier of the target device; the first function concatenates the manufacturer identifier and product identifier of the target device with a preset fixed string to obtain the hardware identifier of the target device. The plug-and-play manager is also used to trigger the driver to call the second function to obtain the compatibility identifier of the target device; the second function concatenates the device type of the target device with the preset fixed string to obtain the compatibility identifier of the target device.

7. An electronic device, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the steps of the device management method as described in any one of claims 1 to 5.

8. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the device management method as described in any one of claims 1 to 5.

Images