JavaOS for Business Device Drivers: Part 1 - Driver Types

Print-friendly Version

JavaOS for Business index

for Business Device Drivers:
Part 1 - Driver Types:

In the PC, MAC, and UNIX® worlds, writing device drivers has always been considered a complex and esoteric system programming task. Intimate knowledge of device registers, interrupt lines, memory management, thread-context switching, and so on are required, since drivers are expected to physically manipulate device hardware. Moreover, because drivers are actually part of the operating system kernel, extreme care must be taken to avoid system crashes. All this makes traditional C language driver writing both a challenge and a chore.

JavaOS for Business software presents an entirely new model for writing drivers. Taking advantage of object-oriented capabilities, JavaOS for Business software encapsulates much of the low-level hardware detail in abstract classes and interfaces, providing developers with a streamlined, layered methodology for writing drivers in Java.

Role of Drivers in JavaOS for Business software

The role of drivers in JavaOS for Business software is simply to perform I/O. Drivers implement class and interface methods to ensure the timely and efficient transport of data and control information throughout the JavaOS for Business software system.

Driver Types

JavaOS for Business software device drivers are dynamic system service modules--that is, discrete objects that plug into the operating system to perform specialized or generic I/O. Two types of drivers are present: logical and physical. Logical drivers may be stacked on top of one another or on top of a physical driver. Physical drivers connect directly to the underlying device hardware.

Driver Capabilities

Drivers implement bus manager interfaces to obtain memory, address, and interrupt information. Many drivers also extend device manager classes, which provide common functionality for drivers by device category. This includes SCSI drivers, audio and video drivers, network drivers and so on. In addition, drivers are sometimes characterized by the manner in which they transmit data to perform I/O. Serial and parallel drivers, block drivers, and other functional driver types are included in this group.

Abstracting out these capabilities, JavaOS for Business software drivers facilitate I/O by performing either one or both of the following services:

• Data formatting
• Device control

Consider the case where an application program wants to send data to a fax device. The application data is formatted in an array of bytes and the fax is connected to a serial port on the local machine. The I/O takes place as illustrated in Figure 1.

FIGURE 1 - High-level view of driver I/O

A simplified view of the data formatting and device control performed by the Fax driver classes is illustrated below:

FIGURE 2 - Reformatted byte array

The behind-the-scenes processing is actually more complex than this--various interfaces, bus managers, and device managers have been left out to streamline the flow; nonetheless, the two diagrams capture the base framework for all driver transactions. Depending on I/O concerns, application demands, and device characteristics, the picture may expand dramatically or shrink marginally. But the essential driver I/O paradigm remains intact--JavaOS for Business software drivers facilitate data transmission by providing data formatting, device control, or both.

Driver I/O Scenarios

This section provides a series of real-world examples of device behavior and specific interface types that can be used to access a device or bus. Driver families and various types of bus managers and bus types are introduced. Scenarios are included for the following drivers:

• SCSI Drivers
• PCI Drivers
• SCSI on PCI

In addition, the use of driver class templates is discussed and a high-level overview of the JavaOS for Business software driver framework is illustrated.

SCSI Drivers: All in the Family

Drivers, like people, are sometimes identified by family group. A driver family consists of a device manager and one or more device drivers. The SCSI family, for example, is composed of the SCSI manager and one or more SCSI drivers. The SCSI family maintains relationships with other SCSI objects, such as bus adaptor devices and a SCSI bus interface. The SCSI family portrait looks something like this:

FIGURE 3 - SCSI family

The SCSI family implements a SCSI bus interface to transact business with a SCSI disk driver, which is considered a client of a SCSI bus and in this case may be acting on behalf of a file system to satisfy an I/O request.

Not shown in this figure but essential to the underlying I/O processing that takes place is a SCSI bus manager. Bus Managers insulate device drivers from platform and bus dependencies by providing low-level system services such as memory allocation and interrupt processing. This allows drivers to be written entirely in Java and remain architecture neutral.

Bus managers are provided with the JavaOS for Business software system. This simplifies the task of driver writing by removing bus management concerns. Driver writers are consequently freed of many of the hardware and software encumbrances that plague developers in UNIX® and Windows environments.

With JavaOS for Business software, the driver environment is characterized by streamlined access to system resources, reduced code overhead, and faster development cycles.

PCI Family: Single Parent Model

Within the SCSI family a clear division of labor was evident; the SCSI manager abstracted out common driver functionality and left bus adaptors to deal with specific device implementations. The PCI family, however, operates on a different premise. Call it the single parent model, since PCI managers and drivers are essentially one and the same, exhibiting no real subdivision of labor. The PCI family picture looks like this:

FIGURE 4 - PCI family

Here a file system object is the client of a PCI bus and the PCI family publishes objects that implement the PCI bus interface. Business is conducted by the PCI all-in-one driver/manager. Because the PCI specification mandates the use of standard adaptor hardware, there is no need for multiple, implementation-specific PCI bus drivers. In the PCI family, drivers are embedded within managers. No external division of labor is apparent.

Family Values

The rationale behind this two-family approach to bus and driver organization derives from practical and historical differences in bus types: SCSI buses traditionally deal with I/O in an ad hoc, case-specific fashion, while PCI buses deal with I/O in a standardized, deterministic manner. JavaOS for Business software drivers are flexible and modular enough to accommodate both models. Because JavaOS for Business software eschews a monolithic approach to driver writing, device drivers are able to conform to the framework of the bus architectures they traverse.

Tale of Two Bus Types

To see this in another light, consider the fundamental difference between SCSI and PCI bus types: SCSI is an I/O bus connected to a desktop machine by an external cable. PCI is an expansion bus, with a built-in slots.

Each SCSI driver is matched to a specific SCSI implementation involving a specific SCSI bus adaptor chipset. The SCSI manager abstracts the chipset -independent functions of the SCSI device; the SCSI adaptor driver, on the other hand, defines the chipset - dependent functions that control the hardware on the SCSI device. The situation is entirely different for PCI--because all PCI devices must implement a standard set of configuration registers defined by the PCI specification, there are no chipset-specific adaptor drivers required.

Regardless of differences, however, these two bus types often interact, as demonstrated in the next section.

SCSI on PCI: Adaptive Behavior

Multiple bus bridges can be constructed using adaptors connected to a PCI bus. Since PCI supports multiplexed bus connections, I/O and expansion buses may intersect at the junction of one or more bus bridges.

Strictly speaking, an expansion bus bridge is a chipset device that implements the protocol of an expansion bus. Expansion bus bridges are managed by expansion bus managers, such as the PCI bus manager.

I/O bus adaptors often resides on expansion buses. For example, many SCSI adaptors are designed as PCI devices. In this circumstance, drivers assigned to a SCSI adaptor device are paired with a PCI expansion bus manager. The SCSI adaptor driver uses the PCI bus manager to gain device memory access and interrupt processing support.

JavaOS for Business software, however, encapsulates much of the complexity of this bus bridge behavior within respective I/O and expansion bus families. In practice, bus families may be stacked on top of each other to create a seamless transport mechanism, as illustrated below:

FIGURE 5 - PCI to SCSI bus bridge

In summary, it is worthwhile noting that expansion bus managers insulate the operating system and device drivers from platform and chipset-dependent implementations of the bus bridge. Moreover, the set of all I/O buses, expansion buses and various bus bridges collectively make up the JavaOS for Business software bus transport layer , an infrastructure upon which driver class implementation of data formatting and device control routines takes place.

Driver Class Templates

In JavaOS for Business software, I/O system components can be arranged in a variety of ways to address a nearly limitless combination of clients, devices, interfaces, and buses.

JavaOS for Business software encourages additions to the framework to extend the reach and power of the operating system. Base classes are provided with the system that act as templates for various kinds of drivers and managers.

Figure 6 shows how templates provided with the system can be leveraged into various component aspects of the JavaOS for Business software driver framework.

FIGURE 6 - Driver templates

Figure 6 introduces the Java Platform Interface (JPI), a platform-dependent interface layer that abstracts the underlying hardware, allowing JavaOS for Business software drivers to be platform-independent and written entirely in Java. The JPI works in concert with the Java Driver Interface (JDI) to provide a robust, secure, and loadable driver architecture. These interfaces are covered in more detail in Part II.

Driver Framework Summary

To summarize aspects of the driver framework presented so far, figure 7 illustrates several possible driver/manager/bus layering combinations:

FIGURE 7 - Driver combinations

In Part 2, driver classes and interfaces are described.