HDK Technical Reference

Block device drivers

Block drivers buffer data being transferred between a user-level process and the device using the system buffer cache. Block drivers are normally written for disk drives and other mass storage devices.

DDI implementation

In DDI versions prior to version 8 and on SCO OpenServer 5 systems, block drivers are characterized by the strategy(D2) or strategy(D2oddi) entry point routine that is used for I/O transfers.

Beginning with DDI 8, all non-STREAMS drivers use the biostart(D2) entry point for I/O transfers, so there is no structural difference between block and character drivers. A driver for a device can be opened once for block access and once for character access. The filesystem keeps a cache in memory of all data accessed by the block file; all the caching is handled outside of the device driver.

See Intro(D2) for a list of entry point routines used for block drivers in DDI versions prior to version 8.

DDI drivers for mass storage devices (either SCSI or non-SCSI) usually use SDI. This means using the entry point routines that are documented in Section D2sdi manual pages of the manual pages, with functions from Section D3sdi manual pages to supplement those in Section D3 manual pages, and accessing the structures documented in Section D4sdi manual pages as well as those documented in Section D4 manual pages. See Developing SDI storage drivers.

ODDI implementation

On SCO OpenServer 5 systems, block drivers use the following entry-point routines, documented in the Section D2oddi manual pages:

Block driver entry-point routines

Type Routine Purpose
entry point open(D2oddi) start access to a block device
  close(D2oddi) end access to a block device
  strategy(D2oddi) perform buffered I/O with device
  print(D2oddi) display messages on the console
physical I/O read(D2oddi) perform raw reads from a block device
  write(D2oddi) perform raw writes to a block device
  ioctl(D2oddi) perform I/O control commands
dma_breakup(D3oddi) size I/O request into usable chunks (DMA)  
pio_breakup(D3oddi) size I/O request into usable chunks (PIO)  
device-specific init(D2oddi) initialize the device when the system boots
  intr(D2oddi) handle interrupt from a block device
  start(D2oddi) access device-specific I/O ports
  probe(D2oddi) defines the device for the Device Query Interface

For more information about writing SCO OpenServer 5 block device drivers, see Chapters 7 and 8 of Peter Kettle and Steve Statler, Writing Device Drivers for SCO UNIX.

Raw I/O

Devices, especially storage devices, often offer support for both raw and block I/O. DDI 8 drivers use the biostart(D2) entry point routine for both raw and block I/O, but ODDI drivers and DDI drivers prior to version 8 must code a strategy(D2) entry point for block I/O and read(D2) and write(D2) entry points for raw I/O. The ODDI routines are strategy(D2oddi), read(D2oddi), and write(D2oddi).

When performing raw I/O, a user process can open and read/write directly to a device. All I/O transfers take place directly to the process's address space, without any intervening copying to the kernel address space. The process's virtual-to-physical address translation must be maintained at least for the duration of the transfer, or data could be copied to a totally unrelated physical memory location. In addition, because the I/O request from the user can be initiated as a vector and requests for reads and writes can be interspersed with lseeks, it is necessary to generate a mapping scheme to translate a user process's view of I/O to absolute locations on a device. The physiock(D3) function accomplishes this task for DDI drivers;. the physio(D3oddi) and physck(D3oddi) functions serve the same purpose for ODDI drivers. The functionality provided includes the following:

When programming a block device to support raw I/O, you must generate a set of kernel virtual addresses that the driver can use during the raw I/O operations where user virtual/physical addresses serve as the source or destination of transfer. When doing programmed I/O, the physical memory (corresponding to the user's virtual address) from which the I/O takes place should have a kernel virtual address for the drivers to use. When using DMA, you must ensure that the data is moved to and from the correct physical location. A process's virtual to physical address translation should be unchanged during an I/O data transfer.

See ``DMA'', ``Programmed I/O (PIO)'', ``Memory-mapped I/O'', and ``Memory allocation''.

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