Analysis of the overall structure of USB in Windows XP

Here we mainly talk about the overall structure of the USB driver protocol stack in Windows XP and some important internal data structures. When writing these things, I referred to the related forum posts of Daniel Tiamo. The content is similar and I can't say that it is a repost. The USB protocol stack consists of the following driver files: the USB port. sys USB Host Controller shares the driver code library for The miniport driver to call. USB hub. sys USB bus driver, USB Bus is also a type of USB device. Usbehci. sys usb ehci host controller driver, which belongs to the miniport driver. Usbuhci. sys usb uhci host controller driver, which belongs to the miniport driver. Usbohci. sys usb ohci host controller driver, which belongs to the miniport driver. Usbd. sys USB device drivers share the code library for USB device drivers and bus drivers to call. USB ccgp. sys USB composite device driver. USB stor. sys USB storage device driver. Usbaudio. sys USB sound device driver. USB video. sys USB video device driver. Hidusb. sys usb hid device driver. The host controller driver is the underlying driver of the USB protocol stack, on which is the USB bus driver and then the USB device driver. There are usually other drivers on the USB driver. For example, there is a class driver for the storage device on the usb stor, and a HIDclass driver on the USB. However, the above driver has little to do with the USB driver protocol stack. The relationship between device drivers and specific devices is not the focus of our discussion. Here we will focus on the controller and bus, which are the core of the USB driver protocol stack. We know that USB2.0 has EHCI controller, and USB1.1 has UHCI and OHCI controller. There are three controllers in total. What is the difference between them? This should first talk about the role of the controller. The USB protocol stack is not built out of thin air. Its lower layer is the PCI bus driver (generally, it is not necessarily a PCI Bus ), the role of the controller is to deal with the PCI bus, convert USB functions and operations into a series of operations on the PCI bus, and also serve as the daily management of the usb bus. Different hardware vendors can have their own Controller specifications, which was particularly prominent in the early days of the USB protocol. However, this is not conducive to the development of the entire specification, So we began to unify the interface specification, which can meet most of the needs of everyone, so everyone will use the standard specification. USB 1.1 has formed the OHCI and UHCI camps, while USB only has EHCI. Obviously, the less standard, the less trouble. Compared with UHCI and OHCI, both of them provide support for the USB protocol. However, the hardware implementation of UHCI is relatively low and the cost is relatively low, but the software driving complexity is relatively high, UHCI is mostly used on PCs, and OHCI is mostly used in embedded devices. While EHCI came along with the USB 2.0 specification (because everyone was suffering from the pain of supporting both specifications), it was also backward compatible with UHCI and OHCI. Okay, so much nonsense. You can check the details on the Internet. Next, let's talk about the controller driver. The specifications of each controller differ greatly from those of the underlying PCI bus, but the functions of the controller used to control the USB bus are basically the same-they fully comply with the specifications of USB itself. Therefore, the underlying driver interfaces of major controllers are independent, while the USB Bus Management Department is extracted to form a common code library named usbport. sys. That is to say, USB port. sys is not an independent driver, but a dynamic link library for others to call. This dynamic link library implements the vast majority of controller-driven functions, so we are used to regard it as the subject of controller-driven. This article explains how USB port. sys is going on. It also describes usbd. sys. The role of usbd. sys is similar to that of USB port. sys. It serves as a dynamic link library for USB device drivers and USB bus drivers. However, because usbd. sys has limited functions and is not as prominent as USB port. sys, it is relatively marginalized and ignored in general discussions. The overall structure of the USB driver stack is described here. The functions implemented by USB hub. sys and USB port. sys will be described later. Author masc2008