This project is hosted by:
project page
The purpose of this project is to provide a framework, or a foundation that can make developing SCSI target devices on Linux easier. The core of the framework is a Linux kernel module, scsi-target.o, that follows the SCSI Architecture Model (SAM-2) and implements (part of) the SCSI Primary Commands (SPC-2).
The core module is designed to support multiple target ports and multiple logical units. Target ports are created by modules that implement certain SCSI transport protocol standards, such as SBP-2 and iSCSI. Through a target port, a SCSI initiator, or a client, can access logical units inside the target. A logical unit contains a device that responds to SCSI service requests sent by the initiators connected through the target ports.
Device modules and protocol modules are also Linux kernel modules therefore an installation site can choose whatever suit the need.
For Linux kernel version 2.4.2x. Porting to 2.6 kernel has been planned.
Follows the standard, except:
command queuing with all types of task tags
Basic task management model defined in SAM-2 is supported.
relative address and linked commands
Will not touch them until it's time to implement SSC. They are not for direct-access devices such as disks and CD-ROM.
normal contingent allegiance
async event reporting
The code is there but not tested. And it is messy and likely buggy.
hierarchical addressing model
A flat addressing model is implemented to assign LUN to logical units. As a compile option, the maximum number of logical units within one system is 256.
The following SPC commands are implemented:
INQUIRY
Support standard INQUIRY data and vital product data (page code 80h "Unit serial number", 83h "Device identification" and 00h "Support vital product data pages").
REQUEST SENSE
TEST UNIT READY
REPORT LUNS
MODE SENSE(6), MODE SENSE(10)
In addition to mode pages defined by device modules, the core module supports the following mode pages:
0Ah "control mode page"
3Fh "all mode pages"
MODE SELECT(6) and MODE SELECT(10) are half-done.
Done with the following exceptions:
reconnection hold
The fetch agent does not hold the login descriptors in case of serial bus reset. It logs out all initiators immediately
A trivial RBC device that uses a chunk of memory to store data and behaves like a disk. Because the medium is volatile, it is of no pratical use. It is for testing only. And for the curious, "dim" stands for "disk in memory".
Completed.
Module parameters:
dim_capacity
Specifies the capacity of a device, in MB (that's 1048576 bytes). Default value 16. The module allocates the memory with the vmalloc() function. Use a number that suits your machine.
dim_devices
Specifies how many devices to create. Default value 1.
A "real" RBC device that sits on top of the Linux block device layer and uses the buffer cache. So in theory it is able to access any block device that is supported by Linux.
Still work in progress.
If you not comfortable with building Linux kernel modules outside the kernel source tree, or if you don't know what I am talking about, you might want to stop here and come back later.
Choose the hardware.
You need at least one of the following controller cards to run the transport protocol module of your choice:
IEEE 1394 (aka FireWire) for SBP-2
If you want to try device modules other than rbc-dim.o or rbc-blk.o, you need the device driver for the specific hardware.
Apparently, you also need to have the initiator, or the client machine, prepared. For example, install the same kind of controller card and the device driver. And make sure it works so you won't be confused by problems that are beyond the scape of Linux SCSI Target.
Prepare the kernel source tree.
You need a kernel source tree from which the system you will run the modules was built.
Download the tarball and extract the source code.
Modify the Makefile(s).
The build scripts are not yet smart enough to detect your environment. You need to tell it where the kernel source tree is and architecture of the target system.
The kernel source tree location is specified by the KERNEL variable in the file Rules.Make. The architecture is specificy by the ARCH variable in the same file. Only x86 has been tested so far.
Compile.
Before setting out to compile, you need to create a directory named as "bin" in the same directory where the file Rules.Make is. Kernel modules will be copied into the bin directory.
make install compiles everything and "installs" the kernel modules into the abovementioned bin directory.
I use GCC 3.3.3 from Debian unstable to compile the kernel and the modules.
Install the modules.
If you compiled the kernel modules on the target system, skip to the next step. Otherwise, you need to transfer the module files to the target system.
Load the modules and plug in the cable.
Note that the transport protocol and device modules must be loaded after the core module scsi-target.o as they depend on it.
Now you can plug in the cable and try to access the target device. Depend on the operating system of the initiator, you probably need to "scan" the specific bus to discover the new device.
All source code of this project are available under the terms of GNU General Public License. You should get a copy of the license text with the source code package.
The first release, 2.4-20040319, is out. As the release name suggests, it is for 2.4 Linux kernel and released on March 19, 2004. To download the source code, go to the project page: http://sourceforge.net/projects/lst/
Thanks to Anmar Oueja and Mark Crewson for inspiring and encouraging me to work on this project.
Special thanks to Ye Ma for helping me start the project and loaning me the hardware.