Structured analysis and design in the redesign of a terminal and serial printer driver - a terminal and serial printer driver for HP's MPE/iX operating system - Technical

Hewlett-Packard Journal, August, 1994 by Catherine L. Kilcrease

This paper describes the use of structured analysis with real-time extensions and structured design in the redesign of the terminal and serial printer driver for the MPE/iX operating system on the HP 3000 computer system. The redesign project objectives were to:

* Maintain the current block mode performance (the main mode of data transfer for terminal I/O is to transfer characters in blocks of data)

* Improve HP 3000 transaction processing performance on industry-standard benchmarks by 5% to 10% through a 20% to 40% reduction in the terminal driver path lengths

* Maintain the current level of functionality

* Produce a high-quality, supportable, and maintainable product.

The project team felt we could not achieve these goals with the then-current development techniques. Object-oriented methods were ruled out because of the performance requirements. We elected to use structured analysis(1) with real-time extensions and structured design.(2)

The Redesign Project

The original driver was based on the terminal driver of the HP 3000 MPE V operating system. During its design, specification of the terminal and printer subsystem was unclear and led to many problems. Since the original driver had added many features since its first release, it was important to have a complete specification of the subsystem to meet the project goals. Structured analysis provided this.

The original driver consists of seven modules that handle the I/O between the HP 3000 file system, the MPE/iX operating system, and the data communication and terminal controller (DTC) (Fig. 1). There are two storage managers. The terminal storage manager provides the interface between HP 3000 file system read and write intrinsic calls and the terminal logical device manager or fast write concat procedure. The serial printer storage manager provides the interface between HP 3000 file system write intrinsic calls and the serial printer logical device manager. High-level I/O is the old path between the file system and the logical device managers. It generally handles non-read/write I/O (controls, opens, closes). There are two logical device managers: one for terminals and one for serial printers. The logical device managers transfer data between the user stack and the data communication buffers for reads, writes, and controls. The fast write concat procedure processes writes received from the terminal storage manager and sends them to the terminal and serial printer device manager (it provides a faster write path for terminals). The terminal and serial printer device manager communicates read, write, and control information to the data communication and terminal controller (DTC) through the Avesta Device Control Protocol. The lower interface of this protocol is the flow control manager. The flow control manager provides reliable transport between the HP 3000 and the DTC by implementing a transport protocol called the Avesta Flow Control Protocol. The storage managers and fast write concat procedure are invoked by procedure calls. The interface between the other modules in the driver and the operating system is message-based via MPE/iX ports.

[CHART OMITTED]

Path trace utility traces of the original driver were analyzed to determine good opportunities for path reduction. The redesign architecture then incorporated the best reduction ideas. The performance improvement is gained from streamlining the path for the most common I/O through the use of direct procedure calls, and from a design emphasizing efficient operation.

The new redesigned driver consists of three modules with three layers in each module (Fig. 2). The three layers are logical, device, and transport. The logical layer acquires the resources needed to complete the I/O request and transfers the data from (to) the user stack into (out of) a data communication buffer. The device layer handles the Avesta Device Control Protocol, which is the mechanism to communicate with the DTC. The transport layer implements the Avesta Flow Control Protocol (transport protocol) and interfaces with the LAN driver.

[CHART OMITTED]

The three modules in the redesigned driver are the fast I/O manager, the deferred I/O manager, and the inbound I/O manager. The fast I/O manager is invoked by the file system with a procedure call. It handles the most commonly executed I/O: reads, writes, and terminal controls (e.g., change speed, parity, etc.). It attempts to process each request to completion. If it cannot complete the processing because of the lack of some resource, the fast I/O manager will block until the resource is available. If the I/O cannot be blocked (i.e., it is no-wait I/O), then the fast I/O manager sends the I/O to the deferred I/O manager. If the request cannot be completed because the "window" is closed at the transport level, the request is also sent to the deferred I/O manager. The deferred I/O manager has a message-based interface. It handles deferred requests from the fast I/O manager and I/O requests that are made through the "old" high-level I/O path, such as open, close, and preemptive writes. The inbound I/O manager also has a message-based interface. It receives inbound packets from the LAN driver. If the packet is a reply to an I/O request, the inbound I/O manager sends a message to either the fast I/O manager or the deferred I/O manager, depending on which of the two initiated the request. It also handles asynchronous events.