![[Return to Library]](BOOKSHELF.GIF)
![[Contents]](TOC.GIF)
![[Previous Chapter]](REW.GIF)
![[Next Section]](NEXT.GIF)
![[Next Chapter]](FF.GIF)
![[Index]](INDEX.GIF)
![[Help]](HELP.GIF)
One of the goals of an open systems environment is to provide hardware and software platforms that promote the use of standards. By adhering to a set of standard interfaces, these platforms make it easier for third-party application programmers to write applications that can run on a variety of operating systems and hardware. This open systems environment can also make it easier for systems engineers to write device drivers for numerous peripheral devices that operate on this same variety of operating systems and hardware.
The hardware-independent model describes the hardware and software components that make up an open systems environment. This chapter provides an overview of the hardware-independent model and shows how it relates to device drivers. Although you do not need to know all of the details of this model, a high-level discussion can help to clarify how device drivers fit into the independent model.
Figure 15-1 shows that the hardware-independent model consists of a:
The sections following Figure 15-1 briefly describe these subsystems as they relate to device drivers.
The hardware-independent subsystem contains all of the hardware-independent pieces of an operating system, including the hardware-independent kernel interfaces, user programs, shells, and utilities. Figure 15-1 shows, however, this subsystem also contains extensions and enhancements made by Digital Equipment Corporation. Examples of these extensions are DECnet and support for CD-ROM file systems.
Writing device drivers becomes easier in such an open systems environment because the system design standardizes interfaces and data structures whenever possible. For example, the hardware-independent subsystem contains those kernel interfaces (such as MALLOC and timeout) and data structures (such as buf and uio) that are not affected by the hardware. On the other hand, those interfaces (such as fubyte and suword) and data structures (such as the timer and memory management structures) affected by the hardware are contained in the hardware-dependent subsystem.
Figure 15-1 shows that the hardware-independent subsystem communicates with:
The hardware-independent subsystem communicates with the hardware-dependent subsystem by calling interfaces and referencing data structures and global variables provided by the hardware-dependent subsystem.
The hardware-independent subsystem communicates with the device driver subsystem by using a specific data structure to make calls into the device driver subsystem. This data structure is the device switch table dsent.
![[Previous Section]](PREV.GIF)
The hardware-dependent subsystem contains all of the hardware-dependent pieces of an operating system with the exception of device drivers. This subsystem provides the code that supports a specific CPU platform and, therefore, is implemented by specific vendors. In the case of Digital Equipment Corporation, this code supports the Alpha architecture. However, code could be written to support other CPU architectures. Writing device drivers becomes easier in such an open systems environment because the CPU-specific changes are hidden in the hardware-dependent layer, so minimal or no changes would need to be made to device drivers.
Figure 15-1 shows that the hardware-dependent subsystem communicates with:
The hardware-independent subsystem initiates communication with the hardware-dependent subsystem by calling interfaces and referencing data structures and global variables provided by the hardware-dependent subsystem.
The device driver subsystem initiates communication with the hardware-dependent subsystem by calling some of the same interfaces and referencing some of the same data structures as the hardware-independent subsystem.
The hardware-dependent subsystem initiates communication with the bus support subsystem by calling the bus configuration interfaces. The bus support subsystem also initiates communication with the device driver by calling the driver's autoconfiguration entry points. These entry points are the driver's probe, attach, and slave interfaces.
The bus support subsystem contains all of the bus adapter-specific code. Many buses provide interfaces that are publicly documented and, therefore, allow vendors to more easily plug in hardware and software components. However, the way one vendor implements the bus-specific code can be different from another vendor. For example, the implementation of the VMEbus on Digital Alpha systems is different from Sun Microsystem's implementation of the VMEbus. Isolating the bus-specific code and data structures into a bus support subsystem makes it easier for independent software vendors to implement different bus adapters.
Figure 15-1 shows that the bus support subsystem communicates with:
The bus support subsystem communicates with the hardware-dependent subsystem by calling interfaces and referencing data structures and global variables provided by the hardware-dependent subsystem.
The bus support subsystem communicates with the device driver subsystem during device autoconfiguration through the driver's probe, slave, and attach interfaces. In addition, the bus support subsystem provides interfaces that allow drivers to perform bus-specific tasks.
The device driver subsystem contains all of the driver-specific code. This subsystem is supplied by Digital Equipment Corporation and includes device drivers for hardware supported by Digital. Third-party device driver writers would place their drivers in the device driver subsystem.
Figure 15-1 shows that the device driver subsystem communicates with:
The device driver subsystem communicates with the hardware-dependent subsystem by calling interfaces and referencing data structures and global variables provided by the hardware-dependent subsystem.
The device driver subsystem communicates with the bus support subsystem during device autoconfiguration. This is accomplished through the driver's probe, slave, and attach interfaces. In addition, device drivers can call bus-specific interfaces to perform a variety of tasks. For example, a TURBOchannel device driver calls the tc_isolate_memerr interface to log memory-related errors. Other buses have their own specific interfaces that drivers use to communicate with this subsystem.
Device drivers can also call generic interfaces such as io_copyin to copy data from bus address space to system memory. The advantage to calling the generic interface as opposed to the bus-specific interface is that the generic interface makes the driver more portable across different bus architectures.
The device driver subsystem communicates with the hardware-independent subsystem through calls to interfaces and data structures provided by the hardware-independent subsystem.