New features in SVR5 SDI

New features in SVR5 SDI

SDI 4 is used to implement support for SCSI and non-SCSI storage devices on SVR5. It is based on the SCO SVR5 1 and 2 PDI with enhancements to support new hardware capabilities that are available. SDI version 4 drivers work with any DDI 7, 7mp, 8, and 8mp versions; the DDI version must also be declared in the driver's Master(DSP/4dsp) See ``DDI interface versioning'' for more information about the versioned interface scheme and ``SDI'' for more information about specific SDI versions.

See ``Porting SDI 3 drivers to SDI 4'' for additional information about porting drivers to SDI 4.

New features in SVR5

SDI 4 on SVR5 enhances earlier SDI versions with the following features:

Extended addressing

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.

64-bit physical memory support

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.

Layered drivers

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.

Multipath I/O driver

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

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.

Extended hardware support

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''.

Other DDI 8 features

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.

© 2005 The SCO Group, Inc. All rights reserved.
OpenServer 6 and UnixWare (SVR5) HDK - June 2005