android系统编译SCSI驱动模块

scsi协议驱动模块

为了了解如何寻址和访问一个SCSI设备，你需要懂得设备是如何连接到计算机系统的，下面的图展示了SCSI系统是如何连接到计算机系统的

The following block diagram represents a typical SCSI subsystem and how it is connected to the system.

• CPU - is the central processing unit of the system.

• System I/O Bus - is inherent to the design of the system. You might have a system with a PCI, SBus, VME, or combination of these.

• SCSI controller - interprets the electrical signals between the system I/O bus and the SCSI bus. For more information refer to "SCSI Controller"" below.

• SCSI Bus - is the path from the SCSI controller to the Device interface.

• Device Interface - interprets the electrical signals between the SCSI bus and the device. It is usually built in to the device unit.

• Device Unit - is the actual peripheral such as a disk, tape, or CD-ROM device. A Device unit with a built-in interface makes up the whole peripheral.

• Device Driver - (not shown) is software that enables the operating system to communicate with the device.

The combination of SCSI controller, SCSI bus, device interface and device unit make up the peripheral subsystem. All of these entities must be designed and configured to work together.

To understand how to address and access a SCSI device you need to understand how the device is connected to the system. The following section describes how SCSI systems are connected to a system.

The scsi support in the linux kernel can be modularized in a number of different ways depending upon the needs of the end user. To understand your options, we should first define a few terms.

The scsi-core (also known as the “mid level”) contains the core of scsi support. Without it you can do nothing with any of the other scsi drivers. The scsi core support can be a module (scsi_mod.o), or it can be built into the kernel. If the core is a module, it must be the first scsi module loaded, and if you unload the modules, it will have to be the last one unloaded. In practice the modprobe and rmmod commands (and “autoclean”) will enforce the correct ordering of loading and unloading modules in the SCSI subsystem.

The individual upper and lower level drivers can be loaded in any order once the scsi core is present in the kernel (either compiled in or loaded as a module). The disk driver (sd_mod.o), cdrom driver (sr_mod.o), tape driver [1] (st.o) and scsi generics driver (sg.o) represent the upper level drivers to support the various assorted devices which can be controlled. You can for example load the tape driver to use the tape drive, and then unload it once you have no further need for the driver (and release the associated memory).

The lower level drivers are the ones that support the individual cards that are supported for the hardware platform that you are running under. Those individual cards are often called Host Bus Adapters (HBAs). For example the aic7xxx.o driver is used to control all recent SCSI controller cards from Adaptec. Almost all lower level drivers can be built either as modules or built into the kernel.