CHAPTER 8
Device Drivers (Equipment Drivers)
One of the targets of the operating system is to cover the user's particularity of the system hardware device. For example, a virtual file system presents a unified file system view with a user, while the underlying physical device is independent. This chapter describes how Linux kernels manage physical devices in the system.
The CPU is not the only smart device in the system, and each physical device is made by its own hardware controller. The keyboard, the mouse, and serial port are controlled by the superIO chip, the IDE disk is controlled by the IDE controller, and the SCSI disk is controlled by SCSI controller, and so on. Each hardware controller is made by its own control and status register (CSR), and different devices have different registers. An Adaptec 2940 SCSI controller's CSR and NCR 810 SCSI controller CSR is completely different. CSR is used to start and stop devices, initializing devices, and diagnosing it. Managing these hardware controllers is not placed in each application, but placed on the Linux kernel. These processes or manage the software of the hardware controller are called device drivers. Essentially, the device driver of the Linux kernel is privileged, residing in the shared library of low hardware control routines. It is Linux's device driver to handle the features of the devices they manage.
A basic feature of UNIX is that it abstracts the processing of the device. All hardware devices are as seen as regular files: They can be used to open, close, and read and write with the same, standard system calls available, standard system calls. Each device in the system uses a special file representative. For example, the first IDE hard disk in the system is represented by / dev / had. For blocks (disks) and character devices, these devices are created with mknod commands, and describe the device using the main (MAJOR) and sub-device number. Network devices also use equipment special files, but they are created by Linux when they are found and initialize the network controller in the system. All devices controlled by the same device driver have a common MAJOR device number. The secondary device number is used to distinguish between different devices and their controllers. For example, different partitions of the main IDE disk have a different sub-device number. Therefore, / dev / hda2, the second partition of the main IDE disk, its main device number is 3, and the secondary device number is 2. Linux uses the master table and some system tables (such as character device table chrdevs) to map the device special files (such as installing a file system on a block device) on a device driver.
See fs / defices.c
Linux supports three types of hardware devices: characters, blocks, and networks.
l Character devices are devices that are not buffered, such as serial port / dev / coA0 and / dev / cua1 of the system.
The L block device is a device that can only be read and written in a multiple of one block (typically 512 bytes or 1024 bytes). Block equipment Access to Buffer Cache, can be randomly accessed, that is, any block can be read, do not have to consider where it is in the device. Block equipment can be accessed through special files of their equipment, but more common is to access through file systems. Only one block device can support a installed file system.
l Network devices are devices accessed through the BSD Socket interface, and the network subsystem is described in the network chapter (Chapter 10).
Linux has many different device drivers (this is also one of the power of Linux), which all have some general attributes:
Kernel Code
The device driver and other code in the kernel are similar, and it is part of the KENEL, and if an error occurs, it may seriously damage the system. A rough driver may even destroy the system, may damage the file system, lose data.
Kenel Interfaces
The device driver must provide a standard interface to the Linux kernel or its subsystem. For example, the terminal driver provides a file I / O interface to the Linux kernel, and the SCSI device driver provides SCSI device interface to the SCSI subsystem, then providing a file I / O and Buffer Cache interface to the kernel.
Kernel Mechanisms and Services
The device driver uses standard kernel services such as memory allocation, interrupt forwarding, and waiting queue to complete work.
Luadable
Most Linux device drivers can be loaded as a kernel module when needed, and uninstall when needed. This makes the kernel very adaptive and efficient for system resources.
Configurable
The Linux device driver can be built in the kernel. As for which devices are established to the kernel, it can be configured when compiling kernel.
Dynamic
When the system is started, each device starts the program initialization, it will find the hardware device it managed. If there is no relationship if the device controlled by a device driver does not matter. At this time, the device driver is only redundant, which takes up very little system memory without harm.
8.1 Poling and Interrupts (polling and interruption)
When each time gives the device command (eg, "Push the read head to the 42nd sector"), the device driver can choose to use what means to determine if the command has been completed. The device driver can poll the device or interrupt.
Polling devices typically mean constantly reading its status registers until the status change of the device indicates that it has completed the request. Because the device driver is part of the kernel, if the driver has been polling, the kernel cannot run other things before the device completes the request, it will be a heavy loss. So polling device drivers use a system timer to make the kernel call one of the routines in the device driver later. This timer routine checks the status of the command, and Linux's floppy disk driver works this. The timer is used to polling is a best approximate, while more effective ways is to use interrupts.
Interrupt driven device drivers will issue a hardware interrupt when its controlled hardware device is required. For example: When a Ethernet message is received on the network, the Ethernet device driver is interrupted by the device. The Linux kernel must be able to forward the interrupt from the hardware device to the correct device driver. This is implemented by the device driver registers the interrupt it uses to the kernel. It registers the address of the interrupt handler routine and it wants to have interrupt numbers. You can see which interrupts and each type of interrupt is used by the device driver and how many interrupts are used:
0: 727432 Timer
1: 20534 KEYBOARD
2: 0 cascade
3: 79691 Serial
4: 28258 Serial
5: 1 Sound Blaster
11: 20868 AIC7xxx
13: 1 Math Error
14: 247 IDE0
15: 170 IDE1
Request for interrupt resource occurs when the driver is initialized. Some interrupts in the system are fixed, which is a legacy of the IBM PC architecture. For example, the floppy drive controller always uses interrupt 6. Other interrupts, such as the interruption of the PCI device, dynamically allocate when started. At this time, the device driver must first identify the interrupt number of the device it controls, and then request the processing of this interrupt. For PCI interrupts, Linux supports standard PCI BIOS callbacks (Callback) to determine information in the system, including their IRQ. A interrupt itself is forwarded to the CPU, depending on the architecture. However, in most architectures, interrupts are transmitted in a special mode, in which other interruptions in the system will be stopped. The device driver should do as little as possible in its interrupt processing routine, so that the Linux kernel can end the interrupt and return to it before it is interrupted. After receiving the interruption, you need to do a lot of work, you can use the kernel's Bottom Half Handler or task queue to bring the routine in the back to call later.
8.2 Direct Memory Access (DMA)
When the amount of data is less than the amount of data, the device driver driven by the interrupt drive is transmitted to the device or receives it from the device. For example, a 9600 baud rate MODEM is approximately one character to each millisecond (1/1000 second). If the interrupt delay is that the time from the hardware device issues to the interrupt handler in the device driver is less than the time (such as 2 milliseconds), then the influence of data transmission on the overall performance of the system is very small. The 9600 baud rate MODEM data transfer will only take 0.002% of the CPU processing time. But for high speed devices, such as hard disk controllers or Ethernet devices, data transmission rates are quite high. A SCSI device can transmit information up to 40M bytes per second.
Direct memory access, or DMA, is the invention to solve this problem. A DMA controller allows data to be transferred between the device and system memory without the need for processor intervention. The PC's ISA DMA controller has 8 DMA channels, and 7 of the device drivers can be used. Each DMA channel is associated with a 16-bit address register and a 16-bit count register (Count register). In order to initialize a data transfer, the device driver needs to set the address and count register of the DMA channel, plus the direction of data transmission: read or write. The device can then tell the device: it can start the DMA when needed. When the transmission ends, the device is interrupted. In this way, transmission can occur when the CPU is made for other things (not required to participate).
When using DMA, the device driver is very careful. First, all DMA controllers do not know virtual memory, which can only access physical memory in the system. Therefore, the memory required to perform DMA transmission must be a continuous physical memory block. This means that you cannot access DMA access directly to the virtual address space of a process. However, you can lock the physical page of the process when performing DMA operations to memory, preventing the physical page from being swapped when doing DMA operations. Second: The DMA controller cannot access all physical memory. The address register of the DMA channel represents the top 16 bits of the DMA address, followed by the 8 bits from the page register. This means that the DMA request is limited to 16M memory at the bottom.
The DMA channel is a rare resource, only 7, and cannot be shared between the device driver. Like the interrupt, the device driver must have the ability to find which DMA channel it can use. As interrupted, some devices have a fixed DMA channel, such as a floppy drive, always using DMA channel 2. Sometimes, the DMA channel of the device can be set with jumper: Some Ethernet devices use this technology. For some more flexible devices, you can tell it which DMA channel is used (through their CSR), at this time, the device driver can simply select a available DMA channel. Linux tracks the use of the DMA channel using the DMA_CHAN data structure meter (one of each DMA channel). The DMA_CHAN data structure has only two domains: a string pointer describes the master of this DMA channel; a flag shows if this DMA channel has been assigned. When you catch Cat / Proc / DMA, it is displayed in the DMA_CHAN vector table.
8.3 Memory (memory)
The device driver must be careful to use memory. Because they are part of the Linux kernel, they cannot use virtual memory. Each time the device driver is running (may be received, a BUTTOM HASALF HANDLER or handler tasle queue) may change. The device driver cannot rely on a special process that is running, which is afraid that the driver is working for the current process. Like other parts of the kernel, the device driver uses the data structure to track the device it controls. These data structures can be static allocated in the code part of the device driver, but this will make the kernel unnecessarily increased to cause waste. Most device drivers allocate kernel, missed memory to store their data.
The Linux kernel provides the kernel's memory allocation and release routines, and the device driver is using these routines. The kernel memory is assigned, and the size of the block is 2 power. For example, 128 or 512 bytes, even if the number of device driver requests is not so much. The number of bytes requested by the device driver, according to the size of the block (greater than or equal to the size of its minimum block). This makes the kernel's memory recovery easier because smaller idle blocks can be combined into larger blocks.
When the kernel memory is requested, Linux also needs to do more additional work. If the total number of idle memory is too small, the physical page needs to be discarded or written to the switch. Typically, Linux will hang a requestor and put this process in a waiting queue until you have enough physical memory. Not all device drivers (or actually Linux kernel code) all want to happen, you can ask the kernel memory allocation to fail without assigning memory immediately. If the device driver wants to access the memory for DMA, it also needs to indicate that this memory is a DMA. Because it is necessary to make the Linux kernel understand which of the system can be continuous, the DMA memory can be made, not the device driver is determined.
8.4 Interfacing Device Drivers with The Kernel (Device Driver and Core Interface)
The Linux kernel must be able to interact with standards and device drivers. Each class of equipment drivers: characters, blocks, and networks provide a general interface for use when requested to request their services. These universal interfaces mean that the kernel can be seen exactly the same as very different devices and their device drivers. For example, the behavior of SCSI and IDE disks is very different, but the Linux kernel uses the same interface to them.
Linux is very dynamic. Every time the Linux kernel starts, it may encounter different physical devices to require different device drivers. Linux allows you to include the device driver in the kernel when the script is created. These device drivers are initialized when the system is started, and they may not find any hardware that they can control. Other drivers can be loaded as a kernel module when needed. In order to process this dynamic characteristics of the device driver, the device driver should be registered to the kernel when they initialize. Linux maintains a list of registered device drivers, as part of their interface. These lists include routine pointers and interface information for supporting this class. 8.4.1 Character Devices (Character Equipment)
Character devices, the simplest device in Linux, can be accessed as files. The application uses standard system calls open, read, write, and shuts down the character device, and treats them as ordinary files. Even if you are used by the PPP daemon, it is used to connect a Linux system to the MODEM, and is also seen as an ordinary file. When the character device is initialized, its device driver registers the Linux kernel, adds a Device_Struct data structure entry in the Chrdevs vector table. The main device identifier of this device (for example, a TTY device is 4), used as an index of this vector table. The master identifier of a device is fixed. Each entry in the chrdevs vector table, that is, a device_struct data structure, including two elements: one is a pointer to the registered device driver name; the other is a pointer to a set of file operations. This group of files is in the character device driver of this device, each handling a specific file operation, such as opening, reading, writing, and off. / proc / devices in character devices from chrdevs vector table
See include / linux / major.h
When a character device (such as / dev / cua0) is opened, the kernel must do something to call the correct character device driver file operation routine. Like normal files or directories, each device special file is expressed in VFS I node. The VFS inode of this character special file contains the MAJOR and Minor identifier of the device. This VFS I node is created by the underlying file system (e.g., EXT2), and its information is provided by the actual file system when looking up this device special file.
See fs / ext2 / inode.c ext2_read_inode ()
Each VFS I node is associated with a set of files, which depend on the file system objects represented by the i node. Regardless of the VFS I node representing a character special file, its file operation is set to the default operation of the character device. In fact, there is only one file operation: OPEN operation. When an application opens this character special file, the universal Open file operation uses the primary device identifier of the device as an index in the Chrdevs vector table, removes the file operation block of this special device. It also establishes the File data structure describing this character special file, allowing its file operation pointer to the corresponding operations in the device driver. Then all file system operations of the application are mapped to the file operation of the character device.
See fs / devices.c chrdev_open () DEF_CHR_FOPS
8.4.2 Block Devices (block device)
The block device also supports the image as a file. Providing a set of correct file operators for opening a special file, this mechanism is very similar to the character device. Linux maintains the registered block device file with the BLKDEVS vector table. Like the chrdevs, the main device number of the block is used as the index of the vector table. Its entry is also a Device_Struct data structure. Unlike character devices, block devices are classified. The SCSI device is one of the categories, and the IDE device is another class. The class registers itself to the Linux kernel and provides file operations to the kernel. It belongs to a device driver for a block device, providing this class with a class-related interface. For example, the SCSI device driver must provide an interface to the SCSI subsystem, and the SCSI subsystem uses these interfaces to provide file operations about such devices to the kernel. See fs / defices.c
Each block device driver must provide an ordinary file operation interface while providing an interface to Buffer Cache. Each block device driver must populate the BLK_DEV_STRUCT data structure in the BLK_DEV vector table. Similarly, this vector table index is also the main device number of the device. This BLK_DEV_STRUCT data structure includes a request routine address and a pointer, which points to a REQUEST data structure list, each Request data structure represents a request from buffer cache, requiring device drivers to read and write a piece of data.
See drivers / block / ll_rw_blk.c, include / linux / blkdev.h
Whenever Buffer Cache wants to read a piece of data from a registered device or want to write a piece of data to a registered device, it adds an REQUEST data structure in its BLK_DEV_STRUC. Figure 8.2 shows that each request is a request to read and write a piece of data, and each Request has a pointer to one or more buffer_head data structures. This buffer_head data structure is locked by the buffer cache, and there may be a process waited for this buffer to complete in this blocking operation. Each request structure is allocated from a static table: all_Request table. If this request is added to an empty request list, the driver's request function is called, starting the processing of the most Request queue. Otherwise, the driver simply handles every request in the Request queue.
Once the device driver completes a request, each buffer_head structure of the request must be deleted from the Request structure and is labeled as the latest, and then unlock. The unlocking of buffer_head will wake up any process that is waiting for this blocking operation. When such an example includes file parsing: The EXT2 file system must read the data block including the next EXT2 directory entry from the block device including this file system, this process will be on buff_head (will include the next EXT2 directory entry) Sleep until the device driver wakes up. This Request data structure is marked as idle, so that it can be used by another block.
8.5 Hard Disks (Hard Disk)
The hard disk stores the data on the rotated magnetic disc to provide a more permanently stored data. In order to write data, the tiny head slides the microplate magnetization of the surface of the disk. The specified particles can be magnetized by the magnetic head to read the data.
A disk drive consists of one or more disks, each of which is made of a relatively smooth glass or ceramic and covering a fine metal oxide. The disk is placed on a central axis and rotates at a stable speed. The rotational speed is from 3000 to 1000 rpm (rotation / per minute) according to the model. In contrast, the floppy rotation speed is only 360 rpm. The disk read / write magnetic head is responsible for reading and writing data, each with a pair, one for each side. The read / write head and the surface of the disk do not have a physical contact, but float on a very thin air cushion (one hundred thousandth inch). The read and write head moves through a driver on the surface of the disc. All the heads are sticky together while moving on the surface of the disc. The surface of each disk is divided into a plurality of narrow concentric rings called tracks. The track 0 is the outermost track, and the highest number of magnetic tracks is the track that is closest to the central axis. A cylinder is a set of tracks with the same number. So the 5th track of all disks on the disk is the 5th cylinder of the disk. Because the number of cylindrical numbers and the number of tracks are the same, the size of the magnetic disk is often described. Each track is further divided into sector (SECTOR). A sector is a minimum data unit that can be read from the hard disk, that is, the block of the disk (block). The usual sector size is 512 bytes. The size of the disk sector is usually set in the disk manufacturing process, which is set to it.
Disks typically describe its size (cylinders) number, heads (heads) number, and sectors. For example, Linux describes my IDE disk when it is started:
HDB: Conner Peripherals 540MB - CFS540A, 516MB W / 64KB Cache, CHS = 1050/16/63
This means that it has 1050 cylindrical (tracks), 16 heads (8 magnetic discs) and 63 sectors / tracks. For a 512-byte sector or block size, the disk capacity is 529200k bytes. This is not compliant with the 516m storage capacity of the disk declaration because some sectors are used as partition information for the disk. Some disks can automatically find bad sectors and re-index them.
The hard disk can be divided into partitions. A partition is a large group of sectors assigned to a particular purpose. Sub-disks so that a disk can be used for several operating systems or more purposes. Most single disk Linux systems have 3 partitions: a DOS file system, the other is an EXT2 file system, and the third is a swap partition. The partition of the hard disk is described with partition tables, each of which is also described by the head, sector, and cylindrical section. For DOS disks formatted with fdisk, there can be four primary disk partitions. But not all four entries in the partition table must be used. FDISK supports three types of partitions: primary partitions, extensions, and logical partitions. The extended partition is not a real partition, which can include any number of logical partitions. The invention extension partitions and logical partitions are to exceed the limitations of four primary partitions. Below is an FDISK output of a disk including 2 primary partitions:
Disk / dev / sda: 64 Heads, 32 Sectors, 510 Cylinders
Units = cylinders of 2048 * 512 BYTES
Device Boot Begin Start End Blocks ID SYSTEM
/ dev / sda1 1 1 478 489456 83 Linux native
/ DEV / SDA2 479 479 510 32768 82 Linux swap
Expert Command: P: P
Disk / dev / sda: 64 Heads, 32 Sectors, 510 Cylinders
Nr Af HD Sec Cyl HD Sec Cyl Start Size ID
1 00 1 1 0 63 32 477 32 978912 83
2 00 0 1 478 63 32 509 978944 65536 82
3 00 0 0 0 0 0 0 0 0 00
4 00 0 0 0 0 0 0 0 00 00
It shows that the first partition begins at cylindrical or track 0, the head 1, and the sector 1 until the cylindrical surface 477, sector 32, and the head 63. Because a track has 32 sectors and 64 read-write heads, the cylinders of this partition are entirely included. FDisk defaults to align the partition on the border of the cylinder. It starts from the outermost cylinder (0), and 478 cylinders are extended inward (head toward the central axis). The second partition (swap partition) begins in the next cylinder (478th cylindrical surface) and extended to the innermost column of the disk.
In initialization, the topology of the hard drive in the Linux mapping system. It finds how many hard drives are in the system and the type of hard drive. Linux also finds how each disk is partitioned. These are expressed by a group of GenDisk data structures directed by GenDisk_head pointers. For each disk subsystem, such as the IDE, when it is initialized, generate the GenDisk data structure to indicate the disk it finds. This process and disk subsystem register its file operation, adding its BLK_DEV_STRUCT data structural entry in the BLK_DEV vector table to occur at the same time. Each GenDisk data structure has a unique main device number (same as the main device number of the block special device). For example, the SCSI disk subsystem creates a separate GenDisk entry ("SD") whose main device number is 8 (all the main device number of all SCSI disk devices is 8). Figure 8.3 shows two genDisk entries, the first is the SCSI disk subsystem, the second is the IDE disk controller. Here the IDE disk controller is an IDE0, an ie the host IDE controller.
Although the disk subsystem will establish a corresponding GenDisk entry when it is initialized, Linux is only used in partition checks. In fact, every disk subsystem maintains its own data structure, allowing own of the primary, secondary device number of the device special file to the partition of the physical disk. Whether it is time to read the block equipment, whether the kernel is oriented to the appropriate device according to the main device number found in the block device special file (such as / dev / sda2), according to the main device number found in the block device (such as / dev / sda2). Each device driver or subsystem maps the secondary device number to a real physical device.
8.5.1 IDE Disks (IDE Disk)
Today's most commonly used disk in the Linux system is an Ide disk (Integrated Disk Electronic). The IDE and SCSI are one disk interface instead of an I / O bus. Each IDE controller can support up to 2 disks, one is master, and the other is from (slave). Master and slave typically set with jumpers on disk. The first IDE controller in the system is called the main IDE controller, the next called slave controller, and the like. IDE can perform 3.3 m / sec data transmission (from / to disk), the maximum size of the IDE disk is 538m bytes. Extended IDE or EIDE increases the maximum disk size to 8.6g bytes, and the data transfer rate is increased to 16.6 m / sec. IDE and EIDE disks are cheap than the SCSI disk, and most modern PCs have one or more IDE controllers on the motherboard. Linux named the IDE disk in order to find the controller. The master disk on the main controller is / dev / hda, the slave disk is / DEV / HDB. / DEV / HDC is the master disk on the Idee controller. The IDE subsystem registers the IDE controller instead of disk. The main identifier of the main IDE controller is 3, the primary identifier of the secondary IDE controller is 22. This means that if a system has two IDE controllers, you will have an entry of the IDE subsystem in the 3th and 22nd items in the BLK_DEV and BLKDEVS vessels. The block special file of the IDE disk reflects this number: Disk / DEV / HDA and / DEV / HDB, both connected to the main IDE controller, and its main device number is 3. All files or buffer operations for these IDE subsystems (such as / dev / hda) represented by block special files are directed to the corresponding IDE subsystem, and the IDE subsystem is used by the kernel as the main device identifier. Index, found in the BLK_DEV and BLKDEVS table. When an request is executed, the IDE subsystem is responsible for determining which IDE disk is designed. To this end, the IDE subsystem uses the secondary device number in the device special file, which allows it to direct the request to the correct partition of the correct disk. / DEV / HDB, the device identifier of the SLAVE IDE disk on the main IDE controller is (3, 64). The device identifier of the first partition (/ DEV / HDB1) on this disc is (3, 65).
8.5.2 Initializing The Ide Subsystem (Initialization Ide Subsystem)
There are IDE disks in most history of IBM PC. During this time, the interfaces of these devices have changed. This makes the initialization process of the IDE subsystem more complicated than it appears for the first time.
The maximum number of IDE controllers that Linux can support is 4. Each controller is represented by an IDE_HWIF_T data structure in the IDE_HWIFS vector table. Each IDE_HWIF_T data structure also contains two IDE_DRIVE_T data structures, which represent the MASTER and SLAVE IDE drivers that may be supported. During the Ide Subsystem Initialization, Linux first checks if information is recorded in the system's CMOS memory. This type of battery does not lose its content when there is a PC shutdown in the backup. This CMOS memory is actually in the real-time clock device of the system, whether your PC is opened or closed, it is running. The location of the CMOS memory is set by the system's BIOS setting, and it tells what IDE controllers and drives found in the Linux system. Linux gets the size (Geometry) of the found disk from the BIOS and uses this information to set this drive's IDE_HWIF_T data structure. Most modern PCs use a PCI chipset such as an 82430 VX chipset, including a PCI EIDE controller. The IDE subsystem uses the PCI (E) IDE controller in the PCI BIOS callback positioning system. Then call these chipset PCI-related query routines. Once an IDE interface or controller is found, set its IDE_HWIF_T data structure to reflect this controller and the disk connected thereto. During the operation, the IDE driver write commands to the IDE command register of the I / O memory space. The default I / O address of the control and status register of the primary IDE controller is 0x1f0-0x1f7. These addresses are early IBM PCs. The IDE driver registers each controller to Linux's Buff Cache and VFS and adds it to the BLK_DEV and BLKDEVS tables. The IDE driver also requests to control the appropriate interrupt. Similarly, these interruptions also have agreed that the main IDE controller is 14, and the secondary IDE controller is 15. However, like all IDE details, these can change with the kernel command line option. The IDE driver also adds an entry to each of the GenDisk list when the IDE driver is started. This list is later used to see the partition tables for all hard drives found when starting. Partition check code understands: Each IDE controller can control two IDE disks.
8.5.3 SCSI Disks (SCSI Disk)
SCSI (Small Computer System Interface Small Computer Interface) Bus is a valid point-to-point data bus, and each bus supports up to 8 devices, each host can have one or more. Each device must have a unique identifier (usually using jumper settings on the disk). The data can be synchronized or asynchronously between any two devices on the bus, and 32-bit width data can be transmitted, and the speed may be as high as 40 m / sec. The SCSI bus can transmit data and status information between devices, a separate transaction between the initiator and the target, may involve up to 8 different phases. You can judge the current phase through the five signals on the SCSI bus. These 8 phases are:
Bus Free
No device controls the bus, there is currently no transaction.
Arbitration (arbitration)
A SCSI device attempts to get the control of the SCSI bus, which declares its SCSI identifier on the address pin. The highest number of SCSI identifiers are successful.
SELECTION
A device successfully obtained the control of the SCSI bus through the arbitration, and now it must send a signal to the SCSI target to send commands. It declares the target's SCSI identifier on the address pin.
RESELECTION
SCSI devices may be disconnected in the process of processing the request, and the target will reselect the initiator. Not all SCSI devices support this phase. Command
6, 10 or 12 bytes of commands can be sent from the initiator to the target.
Data in, Data Out
At this stage, the data is transmitted between the initiator and the target.
STATUS
After completing all the commands, enter this phase. Allow the target to send a status byte to the initiator, indicating success or failure.
Message in, Message Out
Additional information passed between the initiator and the target.
The Linux SCSI subsystem consists of two basic elements, each with a data structure:
Host
A SCSI Host is a physical hardware, a SCSI controller. The NCR810 PCI SCSI controller is an example of SCSI Host. If a Linux system is more than one type of SCSI controller, each instance is represented by a SCSI Host, respectively. This means that an SCSI device driver may control more than one instance of its controller. SCSI Host is usually always the initiator of the SCSI command.
DEVICE
The most common SCSI devices are usually SCSI disks, but SCSI standards support multiple types: tape, CD-ROM, and Generalic SCSI devices. SCSI devices are typically the target of the SCSI command. These devices must be treated differently. For example, the removable medium (such as a CD-ROM or tape), Linux requires detecting whether the medium has been taken out. Different disk types have different master numbers, allowing Linux to direct block devices to the appropriate SCSI type.
Initializing The SCSI Subsystem (Initialization SCSI Subsystem)
Initializing the SCSI subsystem is quite complicated because the dynamic substance of the SCSI bus and the device is to reflect. Linux initializes the SCSI subsystem when started: it looks for the SCSI controller (SCSI host) in the system; detects each SCSI bus and finds all the equipment on it; initializes these devices, so that the rest of the Linux kernel can pass Documents and Buffer Cache block device operations access them. This initialization process has four stages:
First, Linux finds which SCSI HOST adapter or controller has a controlled hardware, which is built in the kernel when the kernel is established. Each built-in SCSI Host has a SCSI_HOST_TEMPLATE data structure entry in the buildin_scsi_hosts vector table. This SCSI_HOST_TEMPLATE data structure includes a pointer to a pointing routine, which can perform and SCSI Host-related action, such as a SCSI device that detects this SCSI HOST. These routines are called when the SCSI subsystem is configured, and is part of the driver that supports this Host type SCSI device. Each SCSI_HOST_TEMPLATE data structure that looks to the SCSI controller (with real SCSI device adhesion) is added to the SCSI_HOSTS list, which represents a valid SCSI Host. Each of the detected Host types is represented by a SCSI_HOST data structure in the SCSI_HostList list. For example, there are two NCR810 PCI SCSI controllers in a system, and there are two SCSI_HOST entries in this list, each controller. Each SCSI_HOST, through the HostT domain, pointing to a SCSI_HOST_TEMPLATE, indicating its device driver.
Now every SCSI Host is found, the SCSI subsystem must find all SCSI devices connected to each Host bus. The SCSI device number ranges from 0 to 7, each device number (or SCSI identifier) is unique on its adhered SCSI bus. The SCSI identifier usually uses jumper settings on the device. The SCSI initialization code finds all SCSI devices connected to a SCSI bus by sending a Test_Unit_ready command to each device. When a device responds, send an ENQUIRY command to read its identifier. At the same time, Linux can also get the name of Vendor, the model and revision number of the device. With a SCSI_CMND data structure, these SCSI commands passed to the device driver by calling the device driver routine in the SCSI Host's SCSI_HOST_TEMPLATE data structure. Each SCSI device found is represented by a SCSI_Device data structure that points to its parent SCSI_HOST. All SCSI_Device data structures are added to the SCSI_DEVices list. Figure 8.4 shows the main data structures and the relationship between them. There are four SCSI device types: disks, tape, CD, and generic. Each SCSI type is registered to the kernel with a different main block device type. Of course, they register themselves when they find one or more given SCSI device types. Each SCSI type, such as a SCSI disk, maintains its own device table. It uses these tables to direct block operations (files or buffer cache) to the correct device driver or SCSI Host. Each SCSI type is represented by an SCSI_TYPE_TEMPLATE data structure. This includes this type of SCSI device information and routine addresses that perform multiple tasks. The SCSI subsystem uses these templates to call the SCSI processing routine for each SCSI device type. In other words, if the SCSI subsystem wants to adhere to an SCSI disk device, it calls the SCSI disk type routine. If a type of one or more SCSI devices are detected, its SCSI_TYPE_TEMPLATES data structure is added to the SCSI_DeviceList list.
The final phase of the SCSI subsystem initialization is to call each registered SCSI_Device_template's finish function. For SCSI disk types, with functions allow all SCSI disks to rotate and record their disk size. It also adds the GenDisk data structure indicating all SCSI disks to the link list of the disk, as shown in Figure 8.3.
Note:
1. The SCSI_HOST_TEMPLATE data structure is described, each class represents a SCSI Host, which defines the related information and operation routines of the class HOST;
2, the SCSI_HOST data structure describes the instance of SCSI_HOST_TEMPLATE (object), indicating a specific SCSI Host;
3, the SCSI_TYPE_TEMPLATES data structure is described, which represents a class of SCSI Device, which contains information and processing routines for such devices;
4, the SCSI_Device data structure describes the instance (object) of SCSI_TYPE_TEMPLATES, indicating a specific device of this type.
DeliveRing block Device Requests (Transfer block device request)
Once Linux initializes the SCSI subsystem, you can use SCSI devices. Each effective SCSI device type is registered in the kernel, so Linux can direct the block device to it. These requests may be by BUFFER CACHE requests for BLK_DEV or by BLKDEVS. Take a SCSI disk drive with one or more EXT2 file system partitions as an example. How does the kernel's buffer request is directed to the correct SCSI disk when it is installed on its EXT2 partition installation? A request for reading and writing a partition of a SCSI disk will cause a new Request data structure that is added to the CURRENT_REQUEST list of this SCSI disk's BLK_DEV vector table. If this Request list is being processed, the buffer cache does not need to do anything. Otherwise it must let the SCSI disk subsystem processed its request queue. Each SCSI disk in the system is represented by a SCSI_Disk data structure. These data structures are stored in the RSCSI_DISKS vector table, part of the secondary device number of the SCSI disk partition as an index. For example, the main device number of / dev / sdb1 is 8, the secondary device number is 17, and its index is 1. Each SCSI_Disk data structure includes a pointer to the SCSI_Device data structure representing the device. SCSI_Device also points to a "owned" SCSI_HOST data structure. The Request data structure from the buffer cache is converted to the SCSI_CMD data structure, which describes the SCSI command that needs to be sent to the SCSI device and queues in the SCSI_HOST data structure representing the device. Once the appropriate data block reads / writes, these commands are processed by their respective SCSI device drivers.
8.6 NetWork Devices
From the perspective of Linux network subsystem, a network device is an entity that sends and receives a packet, usually a physical device, such as an Ethernet card. However, some network devices are pure software, such as a LoopBack device, which is used to send data to themselves. Each network device is represented by a DEVICE data structure. When the kernel is started, the network is initialized, the network device driver registers the device it controls to Linux. The DEVICE data structure includes information of this device and a set of functions, and a large number of network protocols supported by Linux use the service provided by this set of functions. Most of these functions are related to transferring data using this network device. The device uses a standard network support mechanism to transmit the data it receives to the appropriate protocol layer (upper layer). All network data (package packets) of transmission and reception are represented by SK_BUFF data structures, which is a flexible data structure that can easily increase and delete network protocol heads. How to use network devices using network devices, how do they use SK_BUFF data structures to pass data, which will be described in detail in the network chapter (Chapter 10). This chapter focuses on the DEVICE data structure and how the network device is discovered and initialized.
See include / linux / netdevice.h
The DEVICE data structure includes information about network devices:
Name
Unlike block and character devices (their device special files are created with mknod commands), the network device special file is naturally appearing when the network device of the system is discovered and initialized. Their names are standard, and each name represents its device type. Multiple devices of the same type are numbered from 0. Therefore, the Ethernet device is numbered / dev / eth0, / dev / eth1, / dev / eth2, and the like. Some common network devices are:
/ DEV / ETHN Ethernet equipment
/ DEV / SLN SLIP device
/ DEV / PPPN PPP device
/ dev / loopback device
Bus information
This is the information required by the device driver control device. IRQ is an interrupt used by the device. Base Address is the address of the control and status register in the I / O memory. The DMA channel is the DMA channel number used by this network device. All of this information is set when the system is started, and the device is initialized. Interface flags
These markers describe the characteristics and capabilities of the network device.
IFF_UP interface is UP, is running;
The broadcast address of the IFF_Broadcast device is valid;
The debug option of the IFF_Debug device is turned on;
IFF_LOOPBACK This is a loopback device;
IFF_PointTopoint This is a point-to-point connection (SLIP and PPP);
IFF_Notrailers No NetWork Trailers;
IFF_Running resources have been assigned;
IFF_NOARP does not support ARP protocol;
If_promisc devices are receiving the PROMISCUOUS, it will receive all the packages, regardless of who their address;
IFF_allmulti receives all IP MultiCast frames;
IFF_Multicast can receive IP MultiCast frames.
Protocal Information
Each device describes how it can be used by the network protocol layer:
MTU
The size of the maximum package that can be transmitted (excluding a link layer required to increase) is required. This maximum is used by the protocol layer (e.g., IP) to select a suitable sending package.
Family
Family pointed out the protocol supported by the device. Family supported by all Linux network devices is AF_INET, ie Internet address Family.
Type
The hardware interface type describes the media connected to this network device. Linux network devices support a variety of media types. Includes: Ethernet, X.25, Token Ring, SLIP, PPP, and Apple Localtalk.
Addresses
The DEVICE data structure saves some addresses related to this network device, including IP addresses.
Packet queue
This is a queue of a SK_BUFF package that is waiting to be transferred by the network device.
Support functions
Each device provides a set of standard routines that make the protocol layer call as part of the link layer interface of this device. This set of routines include setting routines, frame transfer routines, increase routines such as standard frame headers and collecting statistics. These statistics can be seen in IFCNFIG.
8.6.1 Initializing Network Devices (Initialization Network Device)
Network device drivers, like other Linux device drivers, can be established to the Linux kernel. Each possible network device is represented in a DEVICE data structure that is placed in the list of network devices pointed to by the pointer dev_base. If a device-related operation is required, the network layer calls one of the network device service routines (addresses in the DEVICE data structure). However, when the initial, only the address of the initialization or probe routine is only placed in each DEVICE data structure.
The network driver must solve two problems. First, all network device drivers built in the Linux kernel will have control; secondary, Ethernet devices in the system are always called / dev / eth0, / dev / eth1, etc., regardless of the underlying device driver What is it. "Lost" network device problem (first question) is easy to solve. When the initialization routine of each network device is called, it returns a state that displays whether it is positioned to an instance of the controller it driven. If the driver does not find any devices, it is deleted in the Device list pointed to by DEV_BASE. If the driver can find a device, it fills the rest of the DEVICE data structure with the information of this device and the address of the support function in the network device driver. The second question is to dynamically allocate an Ethernet device to the standard / dev / ethn device special file on a special file, and solve it in a more elegant way. There are 8 standard entry in the Device list: Eth0, Eth1 to Eth7. The initialization routines of all entries are the same, and it tries to build every Ethernet device driver in the kernel until a device is found. When the driver finds its Ethernet device, it fills it now the Ethn Device data structure of Ethn. It is at this time that the network driver should initialize the physical hardware it control, and find out the IRQ, DMA, etc. it uses. The driver may find several instances of the network device it control, in which case it takes up a few / dev / ethn Device data structure. Once all 8 standards / dev / ethn are allocated, there will be more Ethernet devices.
