Electrical computers and digital data processing systems: input/ – Input/output data processing – Input/output addressing
Reexamination Certificate
2000-10-12
2004-06-08
Huynh, Kim (Department: 2182)
Electrical computers and digital data processing systems: input/
Input/output data processing
Input/output addressing
C710S064000, C710S010000, C710S305000, C710S315000, C709S222000
Reexamination Certificate
active
06748459
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates generally to computer networking, and more particularly to a common hardware interface for communication within a Fibre Channel network environment.
2. Description of the Related Art
Conventionally, to provide an interface to hardware devices, software designers often utilize device drivers designed for specific hardware devices. A device driver is a named entity that supports basic I/O functions, such as read, write, get configuration, and set configuration, and typically, also uses and manages interrupts from a device as well.
A device driver is used to provide access to a device from application code in as general purpose a fashion as reasonable, while being as efficient as possible. The interface for a device driver typically is generic and device driver independent, however, the actual driver implementation is completely up to the device driver designer.
As mentioned above, most device drivers are concerned with the movement of information, for example data bytes along a serial interface, or packets in a network. Interrupts typically are used in order to make the most efficient use of system resources, which allows for other application processing to take place, while the data transfers are underway, with the interrupts used to indicate when various events have occurred.
For example, a serial port typically generates an interrupt after a character has been sent “down the wire” and the interface is ready for another. While the data is being sent, further application processing should be allowed since the data transfer can take quite a long time. To allow further application processing, an interrupt is generally used to “alert” the driver and allow the driver to send a new character as soon as the current one is complete, without any active participation by the application code.
One of the first storage and interconnect technologies to utilize device drivers was the Small Computer Systems Interface (SCSI), which is an intelligent, parallel I/O bus on which various peripheral devices and controllers exchange information. Because of its longevity in the marketplace, the parallel SCSI provides a large depth and breadth of products, which include SCSI disk drives, CD-ROM, RAID subsystems, scanners, and other products that are available from a multitude of sources.
To obtain the benefits of the SCSI I/O performance, computer systems use SCSI controllers. A SCSI controller is a hardware device that provides communication with a SCSI network. Communication with the SCSI controller generally is accomplished using a SCSI device driver.
FIG. 1
is a block diagram showing a prior art SCSI system
100
. The SCSI system
100
includes an application program
102
, a SCSI controller
108
, SCSI drives
110
, and a SCSI device driver comprising an operating system module (OSM)
104
and a common hardware interface module (CHIM)
106
. As explained in greater detail subsequently, typically the OSM is operating system dependent, while the CHIM is operating system independent.
During operation the application program
102
executes on a particular operating system, such as WINDOWS
95
, and accesses networked SCSI devices, such as the SCSI drives
110
, using the SCSI device driver. Specifically, when the application program
102
requires access to a SCSI device, such as the SCSI drives
110
, the application program
102
passes a device access command to the SCSI device driver via the OSM
104
section of the SCSI device driver.
Since the OSM
104
is operating system dependent, the OSM
104
varies depending on the type of operating system the application
102
is executing on. Hence, to use the OSM
104
in combination with an application
102
executing on a NT4.0 operating system, the OSM should be designed specifically for the NT4.0 operating system. As shown in
FIG. 1
, the OSM
104
can be designed as a NT4.0 OSM
112
, a WINDOWS 95 OSM
114
, a Linux OSM
116
, a VX Work OSM
118
, a MAC OSM
120
, or any other operating system OSM. In this example, since the application
102
is executing on a WINDOWS 95 operating system, the OSM
104
would actually be a WINDOWS 95 OSM
114
.
When the OSM
104
receives the operating system specific device access command, the OSM
104
translates the command in system independent CHIM device access command for the common hardware interface module (CHIM)
106
portion of the SCSI device driver, and passes the translated command to the CHIM
106
.
Thus, an OSM
104
is written for a specific operating system and completely isolates the CHIM
106
from the host operating system. Typically, the OSM
104
presents device driver entry points that are specific to the particular operating system and converts them to operating system independent calls to the CHIM
106
. Thus, when the operating system calls the driver's initialization entry points, the OSM
104
makes a series of calls to the CHIM
106
that allow the CHIM
106
to check for the presence of adapter hardware, initialize the adapter, and access connected devices.
The CHIM
106
is an operating system independent common hardware interface module that receives CHIM commands and translates the CHIM commands into commands for the SCSI controller
108
.
Whereas the OSM
104
isolates the CHIM
106
from the operating system, the CHIM
106
isolates the OSM
104
from the SCSI controller
108
hardware. The CHIM
106
initializes the SCSI controller
108
hardware, builds commands in the correct format for the adapter, and performs command delivery.
In use, The OSM
104
provides a protocol-specific command, such as a SCSI Command Descriptor Block (CDB), to the CHIM
106
. After receiving the command from the CHIM
106
, the SCSI controller
108
accesses the SCSI drives
110
using the SCSI protocol.
The problem with the prior art SCSI system
100
is that SCSI protocol is often not fast enough to support many modem application needs. The limitations for SCSI in terms of bus speed, reliability, cost, and device count are leading systems and storage designers to look toward serial device interfaces that feature higher data transfer rates.
One such serial device interface is Fibre Channel, which provides a high-speed data transfer interface that can be used to connect systems and storage in point-to-point, switched, or Loop topologies. In addition, the Fibre Channel Arbitrated Loop can support copper media and loops having
126
devices, or nodes.
FIG. 2
is a block diagram illustrating a conventional Fibre Channel system
200
. The Fibre Channel system
200
includes a Port Driver
202
, a Fibre Channel driver
204
, a Fibre Channel controller
206
, and a network device
208
. In use, the port driver passes device access commands to the Fibre Channel driver
204
, which facilitates communication between the port driver
202
and the Fibre Channel controller
206
.
The Fibre Channel driver
204
operates similar to the device drivers discussed previously. Broadly speaking, the Fibre Channel driver
204
provides access to the Fibre Channel controller
206
in as general purpose a fashion as reasonable while being as efficient as possible. Generally, the Fibre Channel controller
206
accesses the network device
208
using a Fibre Channel protocol.
In a Fibre Channel Arbitrated Loop configuration, when a device is ready to transmit data, the device initially arbitrates and gains control of the Loop. Typically, the device accomplishes this by transmitting an Arbitrate (ARBx) Primitive Signal, where x=the Arbitrated Loop Physical Address (AL_PA) of the device. Once a device receives its own ARBx Primitive Signal, the device has gained control of the Loop and can then communicate with other devices by transmitting an Open (OPN) Primitive Signal to a destination device. Once this happens, there essentially exists point-to-point communication between devices.
If more than one device on the Loop is arbitrating at the same time, the x values of the ARB Primitive Signals are compared. When an arbitrating device re
Lin Shing Mark
Lin Yen-Chung
Adaptec, Inc.
Huynh Kim
Martine & Penilla LLP
LandOfFree
Method and apparatus for address mapping does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for address mapping, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for address mapping will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3339102