|
|
See ``Porting SDI 3 drivers to SDI 4'' for additional information about porting drivers to SDI 4.
SDI 4 on SVR5 enhances earlier SDI versions with the following features:
SDI 4 drivers support the extended addressing capability to support larger numbers of configured devices.
Devices in SVR5 are addressed by the template cCbBtTlL, where C represents the card number, B the bus number, T the target number, and L the Logical Unit. This addressing scheme has direct bearing on the special files created under /dev. In SCO SVR5 2.0, this was limited to 32/8/32/32 respectively. In SVR5, this is extended to full 32 bit quantities.
See ``Extended SCSI addressing scheme'' for more information.
DDI 8 enhancements enable
SDI 4 HBA drivers
to access 64-bit physical memory space.
An HBA driver
sets the phys_dmasize member of the
physreq(D4)
structure to specify its capability to access the physical memory.
If this member is set to 64,
the HBA driver can access 64-bit physical memory.
If this member is set to 32,
the HBA driver can only access 32-bit memory.
To avoid memory corruption,
do not set this member to 64
unless the hardware supports 64-bit addresses.
When phys_dmasize is set to 64,
the HBA driver gets all the addresses
as 64-bit quantities.
No additional entry point routines or functions are required
although the driver will need modifications
to understand the 64-bit addresses
that are passed to it.
DDI 8 drivers that needs physical addresses
must specify this as a requirement
by setting BA_SCGTH in
the bcb_addrtypes member of the
bcb(D4)
structure
and must specify the maximum number of scatter/gather elements
that are supported in the
phys_max_scgth member of the
physreq(D4)
structure.
The SVR5 I/O stack is a multilayered stack, supporting layered drivers in addition to the HBA and target drivers supported by earlier SDI versions.
Layered drivers are stacked in the path of the I/O operation. Every layer implements a well-defined piece of functionality and, as such, modifies the I/O operation.
Layered drivers implement the standard operating system operations. Like target drivers, they receive operating system buffers as input but, unlike target drivers, they produce modified operating system buffers as output. This allows for arbitrary stacks to be built as they are for STREAMS device drivers. As new functionality is required, additional layers can be inserted.
As released, SVR5 includes three layered drivers: vtoc, mpio, and RAID. Each of these is discussed below.
The vtoc driver implements the fdisk partition abstraction and the SVR5 slice abstraction. See the manual page for more information.
Newer storage processors and RAID boxes have multiple independent ports to access the same media. Also, some new configurations have multiple Host Adapters on the same bus, allowing independent access to the media through each card.
The mpio driver recognizes the multiplicity of paths, and consolidates them. This allows for it to load balance I/O and recover from failed paths by redirecting I/O through other available paths. It achieves this by putting a unique identifier named stamp on the media. As paths are discovered, stamps are compared and internal data structures are built according to this criteria.
This has some interesting side effects:
The mpio driver also has support for Cache Cohorent Non Uniform Memory Architecture (ccNUMA); see ``Cache coherent NUMA localization''. In broad terms, the issue to be addressed here is that certain memory is substantially more expensive to access than other. Given this knowledge, the mpio driver may decide to route I/O through the least expensive path of memory.
RAID drivers are a class of layered drivers that encapsulate proprietary interfaces to RAID devices. Each vendor of RAID hardware must provide a driver to achieve full O/S support for the device's capabilities. Even though RAID devices and storage processors may comply to some standard interface such as SCSI or Fiber Channel, much of their functionality is not covered under any standard. This is the case for their administrative interface which is usually proprietary and requires software tools to fully take advantage of it. If the software tools require any kernel/driver support, it is here where it should be implemented.
RAID drivers are implemented as SDI 4 layered drivers using DDI 8.
The mpio driver has a particular relationship with these drivers. It has two standard calls into it. The first one allows it to retrieve a proprietary signature, which may be beyond the normal stamp. The second call is to activate ports that may be passive.
Because RAID is a new class of driver, it is anticipated that its definition may be fluid for the time to come.
SCO has partnered with a number of hardware vendors and incorporated the lastest drivers for new Host Bus Adapters into the SVR5 release. SCO offers a broad range of developer programs and support options to support customers who are developing their own device drivers.
SCO also provides the Compatible Hardware Web Pages (CHWP), where vendors can list hardware that is supported on SCO platforms and where customers can go to get an up-to-date listing of all hardware that is available for each platform. See ``Accessing the SCO Compatible Hardware Web Pages''.
In addition to the features discussed above, SDI 4 drivers are enhanced by new DDI 8 features, including:
See ``New driver features in DDI 8 and SVR5'' for more information.