Equipment Model Fantasy, it is only a model, it must be implemented in the specific subsystem, otherwise you can only hold a best technology award empty Hate yourself. Since the previous implementation of the USB subsystem to analyze the example of how the kernel source code should start, then here is still a USB subsystem as an example to see how the device model soft landing.
The structure of the USB subsystem in the kernel
We already know that the USB subsystem code is located under the Drivers/usb directory and also recognizes a very important directory--core subdirectory. Now, let's look at a very important module,--usbcore. You can use the "lsmod" command to see if a module called Usbcore is found in the displayed results.
Localhost:/usr/src/linux-2.6.23/drivers/usb/core # Lsmod
Module Size used by
Af_packet 55820 2
Raw 89504 0
NFS 230840 2
LOCKD 87536 2 NFS
Nfs_acl 20352 1 NFS
SUNRPC 172360 4 Nfs,lockd,nfs_acl
IPv6 329728 36
Button 24224 0
Battery 27272 0
AC 22152 0
AppArmor 73760 0
Aamatch_pcre 30720 1 AppArmor
Loop 32784 0
Usbhid 60832 0
Dm_mod 77232 0
IDE_CD 57120 0
Hw_random 22440 0
EHCI_HCD 47624 0
CDROM 52392 1 IDE_CD
UHCI_HCD 48544 0
SHPCHP 61984 0
Bnx2 157296 0
Usbcore 149288 4 USBHID,EHCI_HCD,UHCI_HCD
e1000 130872 0
Pci_hotplug 44800 1 SHPCHP
ReiserFS 239616 2
Edd 26760 0
Fan 21896 0
??
Have you found Usbcore's line? Core is the kernel, basically you have to use USB device in your computer, then two modules is necessary: One is Usbcore, this is the core module, and the other is the host controller driver, such as here Usbcore that line we see EHCI_HCD and UHCI_HCD, For your USB device to work, the appropriate USB host Controller module is also essential.
Usbcore is responsible for implementing some core functions, providing services to other device drivers, and providing an interface for accessing and controlling USB hardware, rather than considering which host controller The system currently exists in. As shown in the relationship between core, host controller, and USB drive.
USB drive and host controller like the core of the two bodyguards, the protocol also said that the host controller driver (HCD) must be located on the next level of USB software. HCD provides the abstraction of the host controller hardware, hides the details of the hardware, and under the host controller is the physical USB and all USB devices connected to it. And HCD only one customer, is responsible for one person, is usbcore. Usbcore maps the user's request to the relevant HCD, and the user cannot access HCD directly.
Core has done most of the work for us, so when we write the USB drive, we can only call the core interface, and the core will send our request to the corresponding HCD.
USB subsystem and device model
The most important question about the device model is how the bus, device, and driver connect. In other words, how are the pointers in these three data structures assigned to each other? The absolutely impossible thing is that once you have applied a struct BUS_TYPE data structure for a bus, it knows what the devices list and the drivers list will contain, something that must not be innate, but can only be filled in from the day after.
Specific to the USB subsystem, the completion of this work is the USB core. The USB core code will initialize the entire USB system, such as applying for a struct bus_type usb_bus_type, and then scanning the USB bus to see which USB devices are connected on the line, or which USB devices are connected to the root hub For example, if you have a USB keyboard, you will prepare a struct device for it, assign a value to the struct device according to its actual situation, and insert it into the devices linked list.
Another example is the root hub connected to a normal hub, so in addition to the hub itself to prepare a struct device, but also to continue to scan to see if the hub is connected to another device, some words continue to repeat the previous thing, so keep going until the entire scan is completed, Finally, the usb_bus_type in the devices linked list to build up.
So what about the drivers list? This is not the bus side initiative, and each driver itself to the bus above the registration, or listing. Specific to the USB subsystem, each USB device driver will correspond to a struct usb_driver structure, which has a struct Device_driver driver member, USB core for each device driver prepared a function, Let it insert its own struct Device_driver driver into the drivers list in Usb_bus_type. And this function is what we have seen before usb_register. The corresponding Usb_deregister is doing the opposite work, removing the structure from the drivers list.
The match function of the struct BUS_TYPE structure is the Usb_device_match function in the USB subsystem, which acts as a matchmaker, connecting the USB device and USB driver on the USB bus, similar to the bridge version on the Jiaotong University BBS, Although the conditions above are all dazzling, it is obvious that the match condition is not so harsh and more practical.
It can be said that the USB core is really well-intentioned, for each USB device driver to do the homework, because of this, as a real USB device driver, it in the initialization phase of the things to do very little, very simple, directly call Usb_register can. In fact, no one is rightfully supposed to do anything for you, but the USB core does so. So every USB device driver should remember that USB device driver is never a person at work, behind him, is the unknown and indispensable support provided by USB core.
Linux Kernel (8)-Device model (bottom)