Kernels, description tables, and device drivers

Abstract

Description tables can be linked to a kernel to form a device driver. The description tables can be device description tables and adapter description tables. The kernel is operating system dependent. The description tables are operating system independent and can be linked to other kernels for other operating systems. A library of kernels for different operating systems can share a common set of kernel requests.

Claims

What is claimed is:

1. A method for controlling a device on a digital computer system, said digital computer system including:

a central processor including a memory for storing instructions and data,

an adapter attached to said central processor,

a device attached to said adapter, and

an operating system for controlling said central processor, the method comprising:

(a) receiving an operating system request by a device driver kernel, said device driver kernel particular to said operating system;

(b) translating said operating system request by said device driver kernel into an operating-system-independent kernel request;

(c) processing said kernel request to create an adapter request by a device description table, said device description table particular to said device and independent of said operating system and having at least one device action routine and a device action list, said processing said kernel request to form said adapter request by said device description table comprising: selecting one of more device action routines from said device action

list in said device description table necessary for processing

said kernel request;

and executing said selected device action routines; and

(d) processing said adapter request to control said device on said adapter by an adapter description table, said adapter description table particular to said adapter and independent of said operating system and having at least one adapter action routine and an adapter action list, said processing said adapter request to control said device on said adapter by said adapter description table comprising: selecting one or more adapter action routines from said adapter

action list in said adapter description table necessary for

processing said adapter request; and executing said selected adapter action routines.

2. The method of claim 1, said device driver kernel including an environmental map, and said device driver kernel using said environmental map during said translating said operating system request into said kernel request.

3. The method of claim 1, said device description table further having device configuration information, and said device driver kernel selecting said one or more device action routines from said device action list based on said kernel request and said device configuration information.

4. The method of claim 1, said device description table having device configuration information, and said device configuration information used by said one or more device action routines in creating an adapter request.

5. The method of claim 4, said device configuration information comprising information identifying the name of said device, information identifying said adapter as the adapter to which said device is attached, and information identifying said device's address.

6. The method of claim 1, said adapter description table further having adapter configuration information, and said device driver kernel selecting said one or more adapter action routines from said adapter action list based on said adapter request and said adapter configuration information.

7. The method of claim 1, said adapter description table further having adapter configuration information, and said adapter configuration information used by said one or more adapter action routines in processing said adapter request.

8. The method of claim 7, said adapter configuration information comprising information identifying the name of said adapter and information identifying said adapter's address for use by said adapter action routine in processing said adapter request.

9. A method for controlling a device on a digital computer system, said digital computer system including:

a central processor including a memory for storing instructions and data,

an adapter attached to said central processor,

a device attached to said adapter, and

an operating system for controlling said central processor, the method comprising:

(a) receiving an operating system request by a device driver kernel, said device driver kernel particular to said operating system;

(b) translating said operating system request by said device driver kernel into an operating-system-independent kernel request;

(c) processing said kernel request to create an adapter request by a device description table, said device description table particular to said device and independent of said operating system and having:

at least one device action routine,

a device action list, and

device configuration information;

said processing said kernel request to form said adapter request by said device description table comprising:

selecting one of more device action routines from said device action list in said device description table by said device driver kernel based on said kernel request and

said device configuration information;

and executing said selected device action routines; and

(d) processing said adapter request to control said device on said adapter by an adapter description table, said adapter description table particular to said adapter and independent of said operating system and having:

at least one adapter action routine,

an adapter action list, and

adapter configuration information;

said processing said adapter request to control said device on said adapter by said adapter description table comprising:

selecting one or more adapter action routines from said adapter action list in said adapter description table by said device driver kernel based on said adapter request and said adapter configuration information;

and executing said selected adapter action routines.

Description

REFERENCE TO MICROFICHE APPENDIX

The application includes a microfiche appendix containing 12 microfiche having 840 frames.

I. TECHNICAL FIELD

This invention is in the area of device drivers and technology, methods and computer programs relating to device drivers.

II. BACKGROUND ART

A computer system typically includes, in addition to the computer itself, one or more peripheral devices, such as printers, magnetic tape drives, hard disk drives, floppy disk drives, removable cartridge drives, modems, etc. An adapter is used as the hardware connection between a peripheral device and the computer. Computers require special computer programs to support or "drive" the devices. These computer programs are commonly referred to in the computer industry as "device drivers."

Conventionally, each specific kind of device requires a unique device driver. For example, two different types of hard disk drives may require two different device drivers. With the advent of new computer interface standards such as the Small Computer Systems Interface (SCSI), it is possible for a plurality of devices to share a common adapter. However, a plurality of device drivers are often needed for a plurality of different devices even when they are attached to the same adapter.

Prior art device drivers are dependent upon the operating system for which they are written. The device driver must satisfy the device driver requirements of the operating system. A device driver written for one operating system cannot be used with a different operating system.

The ease and success with which a plurality of devices can be attached to a computer have been hampered by the independent development of incompatible device drivers, by the difficulty of testing device drivers for errors when changes or enhancements are made, and by problems arising from the unintended interaction of device drivers with each other or the operating system or other computer programs.

Prior art device drivers attempting to support devices and/or adapters are not flexible in allowing support for specific devices and adapters. The code is closely coupled. Modifications to add or delete devices or adapters cause significant increases in testing and maintenance costs.

The device driver of our invention overcomes these and other limitations and disadvantages of prior art device drivers. It is an objective or our invention to provide a device driver that is flexible and that can be configured to reflect the configuration of devices and adapters selected by the user. Another objective of our invention is to make easier the use of devices and adapters with different operating systems. These objectives and other objectives, advantages and aspects or our invention are described in the following disclosure and claims and in the accompanying drawings.

III. BRIEF SUMMARY AND DISCLOSURE OF INVENTION

Our invention includes kernels, description tables and device drivers and related methods. The invention can be used with a digital computer.

One or more description tables can be linked to a kernel to form a device driver. The kernel and linked description tables can be resident in a computer memory of a digital computer having devices and adapters attached to it. The kernel is linked to the operating system (i.e., the kernel receives operating system requests issued by the operating system). The kernel is operating system dependent and is a means for linking the description table(s) to the operating system. The description table(s) is (are) linked to the operating system, i.e., the kernel and description table(s) form a device driver that receives and processes operating system requests from the operating system. The description tables are operating system independent and can be linked to other operating systems through other kernels. The device driver formed by the kernel and description table(s) receives an operating system request from the operating system, processes the operating system request, creates a device command for the device supported by the device driver, and issues the device command to the device.

Preferably, a device description table and an adapter description table are linked to the kernel. The device description table supports a device attached to the digital computer. The adapter description table supports an adapter attached to the digital computer. The device is attached to the adapter. The kernel can have an environmental map to translate an operating system into a kernel request. The device description table can process the kernel request and create an adapter request. The adapter request can include a device command and an adapter description table command. The adapter description table can process the adapter request and can issue the device command to the device. The adapter description table can also create adapter commands and issue them to the adapter.

The kernels in the library share a common set of kernel requests, i.e., there is a core group of kernel requests used by each kernel. This allows a description table that can process this common set of kernel requests to be used with different kernels supporting different operating systems. It should be noted that some kernels in the library may use additional kernel requests that are not in the common set of kernel requests and are not used by all of the other kernels in the library. Nonetheless, the kernels still share a common set of kernel requests (i.e. the core group).

The kernels in the library can share a common set (i.e. core group) of service routines and/or a common set (i.e. core group) of initialization routines. As with kernel requests, some kernels in the library may use additional service routines and/or additional initialization routines. Nonetheless, the kernels still share a common set of service routines and/or a common set of initialization routines. It should also be noted that the sharing of a common set of service routines does not mean that the code of the service routines for one kernel is identical to the code of the service routines for another kernel. Instead, it should be understood that this means that the service routines perform substantially the same functions. This concept also applies to the initialization routines.

The kernel includes a means for linking the description tables to the kernel. This means can be a table interface such as a global data structure or any other interface or linkage.

The kernel can also include a sequencer for activating and sequencing description tables. The sequencer can be any means which coordinates description table operation.

The kernel can also include a service map for providing service routines to the kernel and/or description tables, and an initialization map for providing initialization routines to the kernel.

The description tables can include action routines. The action routines are executable by the digital computer to cause the desired result, action or function ("action routine function"). The set or list of action routines is an action list. A description table can include a means for selecting an action routine in response to a kernel request or adapter request. This selection means can be any means which performs the selection.

Preferably, the selection means includes a table having references to the action routines in the action list, and an accessing means which can access the table and select an action routine. Although other means can be used to practice our invention, a preferred table of references is a state event table and a preferred accessing means is a cell processor. The state event table can be separate from the cell processor or combined with it.

The kernel and description tables can be loaded into the computer memory of a digital computer and are executable by the digital computer (i.e., the computer programs, routines and data of the kernel and description tables can be executed, read and/or otherwise processed by the digital computer). The kernel and description tables can also be resident in a computer memory storage medium other than a computer memory.

Our invention also includes a library of kernels and description tables from which a kernel and needed description tables can be selected for a given computer system configuration. Each kernel in the library supports a different operating system. The description tables can be linked to any operating system through the kernel for that operating system. The kernels can share a common set of kernel requests. The kernels can also share a common set of initialization routines and/or service routines. The device description table can process the kernel requests created by the kernels.

Our invention further includes special device description tables in the form of logical device description tables, default device description tables and pseudo device description tables. A logical device description table is supported by one or more default device description tables that can be invoked by the logical device description table. A pseudo device description table processes data.

IV. BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 depicts an overview of an embodiment of the inventive device driver.

FIG. 2 depicts an example of a system configuration selected by the user and further depicts the connections and relationships among the devices, adapters, device description tables and adapter description tables.

FIG. 3 depicts a global data structure which serves as an interface between the kernel and the description tables.

FIG. 4 depicts an adapter description table and a device description table.

FIG. 5 depicts an adapter request.

FIG. 6 depicts the processing of an operating system request and includes the environmental map, sequencer, device description tables and adapter description tables.

FIG. 7 depicts the cell processor, state event table and action list of a description table.

FIG. 8 depicts a service map.

FIG. 9 depicts a flow chart describing the steps associated with the initialization and loading of the inventive device driver.

FIG. 10 depicts global description table selectors, a kernel and description tables.

FIG. 11 depicts a device or adapter description table, the memory management portion of the global data structure, and global description table selectors.

FIG. 12 depicts the processing of an operating system request.

V. DETAILED DESCRIPTION OF INVENTION AND BEST MODE FOR CARRYING OUT INVENTION

A. Overview of Invention

FIG. 1 shows an overview of an embodiment of the invention. A kernel 1 includes environmental map 2, sequencer 3, global data structure 4, initialization map 5, service map 6 and queues 7 and 11. Device description tables 8 and adapter description tables 9 are linked to kernel 1 through global data structure 4 which serves as a table interface. The kernel and the linked description tables form a device driver.

The library 10 is a directory which contains kernels, adapter description tables and device description tables which are stored as files. Device description tables include physical device description tables (B1.DEV, B2.DEV, C1.DEV, C2.DEV, . . . ), logical device description tables (DU.DEV, . . . ), and pseudo device description tables (P1.DEV, P2.DEV, P3.DEV, Each of the kernels (KERNEL1.SYS, KERNEL2.SYS, KERNEL3.SYS, . . . ) in library 10 supports a different operating system. For example, KERNEL1.SYS is compatible with the MS-DOS operating system, KERNEL2.SYS is compatible with the OS/2 operating system, and KERNEL3.SYS is compatible with the Unix operating system. Other kernels can be added to the library which support (i.e. are compatible with) other computer operating systems.

The environmental map 2 is a computer program that translates operating system requests into kernel requests. An operating system request is an input-output request which is directed to a device (e.g. hard disk drive, printer, Bernoulli drive, floppy disk drive, tape drive, optical disk, modem, etc.). The kernel requests are common to all kernels in library 10, i.e., the kernels in library 10 each share and use a common set or list of kernel requests. Thus, kernel requests are not unique to a particular kernel but are common to each of the kernels in library 10. This allows a single device or adapter description table created for a particular device or adapter to be used with (i.e. linked to) any of the kernels in library 10 and, therefore, with any of the operating systems for which those kernels are created.

Kernel requests, from environmental map 2, are queued in queue 7 to allow for multi-task operation in those operating system environments which provide multi-task operation. If the operating system in use does not provide multi-task operation, then a single element queue is used.

Service map 6 of Kernel 1 provides service routines to the kernel and the description tables.

Global data structure 4 serves as the kernel's interface with description tables. Because each kernel has this table interface, each description table in library 10 can be used with any of the kernels in library 10. Thus, the description table for a given device or adapter only needs to be written once, i.e., it does not need to be written separately for each kernel or operating system.

The device driver (i.e. kernel 1 and description tables 8 and 9) is assembled as it is loaded from library 10 which contains the various kernels, adapter description tables and device description tables available for selection and use by the user. A configuration file 20 (CONFIG.OAD) controls the assembly of the device driver. This installation specific configuration file is created by the user using the configuration utility 21. The configuration utility is a computer program which is used by the user to define the system configuration selected by the user. The configuration utility also checks for compatible configurations and provides information to the kernel which is specific to a description table but is independent of the user's configuration and is not known by the user.

Device description tables translate kernel requests into device specific information. Because the kernel requests are common to all kernels in library 10, the description tables can process kernel requests from any kernel in library 10. The device description tables can execute kernel requests and create adapter requests. The adapter requests include device commands and adapter description table commands. These adapter requests are queued in adapter request queue 11 by kernel 1 synchronous to the operating system 12. Device description tables may also recursively pass control to other device description tables which can add adapter requests to the queue.

Adapter requests can function in a single thread environment with operating system such as MS-DOS, or in a multiple thread environment with other operating systems such as OS/2 and Unix.

Adapter description tables 9 receive adapter requests and process the adapter requests, e.g., process the adapter description table commands and issue the device commands to devices. Adapter description tables can also create adapter commands. The output (i.e. device commands and adapter commands) from adapter description tables 9 can be issued to devices and adapter in accordance with conventional procedures using DMA (Direct Memory Access), PIO (Programmed Input/Output), Bus Master, Memory Map, BIOS (Binary input Output System) or direct register commands on the adapters or in accordance with any other procedures now known or later developed for issuing device commands to devices and/or for issuing adapter commands to adapters. Adapter description tables 9 can operate asynchronous to the operating system and can respond to interrupts. Interrupts and other asynchronous commands are supported by the service routines in service map 6 of kernel 1.

An operating system request interface into kernel 1 is typically included as part of operating system 12. The operating system request interface receives normal operating system requests such as read data and write data and is described in the technical reference manuals for the specific operating system in use. These operating system requests normally vary from operating system to operating system but are translated into common kernel requests by the environmental map 2. These kernel requests are executable by any of the description tables in library 10.

The operating system request interface can also contain an IOCTL interface which can be used to create requests not created by the operating system. These IOCTL requests are a special kind of operating system request and can be processed by the inventive device driver as operating system requests. Vendor created IOCTL request packets are associated with the IOCTL interface and the IOCTL requests. An IOCTL request packet can be referenced by a device description table using a pointer to the IOCTL request packet. The pointer is included in the IOCTL request (operating system request) and in the kernel request issued by the device description table. The implementation of this kernel request is completed by the device description table 8 which uses the IOCTL request packet to create one or more adapter requests (device commands).

Device description tables 8 and adapter description tables 9 can be linked (e.g. attached) to any of the kernels in library 10 in any combination. Description tables operate independently of other description tables. The kernel provides the capability to ensure that each description table operates independently of other description tables. Thus, each description table can be created and tested in a stand alone environment and can be linked to any kernel in library 10 in any sequence and in any combination with other description tables.

In summary, the device driver provides three types of translation functions:

1. The kernel (through its environmental map) translates operating system requests into common kernel requests.

2. Device description tables translate kernel requests into device specific information, e.g. adapter requests, calls to other description tables, etc.

3. Adapter description tables translate adapter requests into adapter specific information, e.g. issuance of device command, etc.

B. Configuration of System

The invention supports considerable configuration flexibility. FIG. 2 represents a sample configuration of a system. As shown in FIG. 2, several devices 30, 31, 32, 33 and 34 are attached to the system through adapter cards 35 and 36. These devices can be any of a wide variety of peripheral devices. For example, device 30 (B11,0) can be a master Bernoulli cartridge drive, device 31 (B11,1) can be a slave Bernoulli cartridge drive, device 32 (C12,0) can be a CD-ROM player, device 33 (B2 1,0) can be a hard disk drive, and device 34 (C2 6,0) can be a helical scan tape drive. The adapters can represent intelligent or nonintelligent SCSI adapters and/or other adapters. For example, adapter 35 can be an Iomega PC2 SCSI adapter and adapter 36 can be an Adaptec intelligent SCSI adapter. In this embodiment of the invention the Small Computer Systems Interface (SCSI) is used between the adapters and devices. In other embodiments of the invention other interfaces (e.g. ESDI, etc.) can be used singularly or in combination. To support the hardware (i.e. the devices and adapters), the invention uses a kernel (shown as kernel 1 in FIG. 1) to which are linked description tables 37, 38, 39, 40, 41, 42 and 43 for the devices and adapters.

As shown in FIG. 2, the description tables for the physical devices and adapters mirror the physical hardware configuration of devices and adapters. An adapter description table is assigned for each adapter 35 and 36, a device description table is assigned for each physical device 30, 31, 32, 33 and 34. Device description table 37 corresponds to device 32. Device description table 38 corresponds to device 30. Device description table 39 corresponds to device 31. Device description table 40 corresponds to device 33. Device description table 41 corresponds to device 34. Adapter description table 42 corresponds to adapter 35. Adapter description table 43 corresponds to adapter 36. An address representation is made for each of the devices and adapters. In FIG. 2, SCSI interface addressing is used with the SCSI ID, LUN notation. As an example 6,0 represents SCSI ID 6, LUN 0 and is the SCSI interface address of device 34 (C2 6,0). As another example, device 31 (B1 1,1) has a SCSI interface address represented by SCSI ID 1, LUN 1.

An additional level of function is provided by special description tables which are assigned to logical devices and pseudo devices. In FIG. 2, device description table 45 is a logical device description table. Also in FIG. 2, device description tables 46, 47 and 48 are pseudo device description tables. Pseudo device description table 46 provides post-processing (for example decryption). Pseudo device description table 47 provides pre-processing (for example encryption). Pseudo device description table 48 provides both pre-processing and post-processing (for example a peripheral cache). The logical and pseudo device description tables do not mirror the physical devices shown in FIG. 2 because there are no physical devices which correspond directly to these device description tables.

When the operating system presents an operating system request to the kernel the operating system expects one of two types of devices: a character device or a block device. Character devices and block devices are defined in the definitions of Section VI. Associated with each character device (unless it is a default device) is a device name. Associated with each block device (unless it is a default device) is a unit number. In FIG. 2, devices 32 and 34 are character devices having the names $C1 and $C2 respectively. Device 30 is a block device having unit number 0.

Devices 31 and 33 are block devices but do not have unit numbers because they are default devices. Device description tables 39 and 40, which correspond to devices 31 and 33, are attached to logical device description table 45. (Note: "attached" means that description tables are loaded into computer memory and linked to the kernel through entries in the global description table. Device 31 and its description table 39 are not assigned a unit number by the operating system. Device 33 and its description table 40 are not assigned a unit number by the operating system. Devices 31 and 33 are default devices because they are not assigned a unit number or character name by the operating system. Thus description tables 39 and 40 are default device description tables.

Devices 30, 32 and 34 are "real devices" because they are physical devices to which the operating system has assigned a unit number or character name. In FIG. 2, device 30 has been assigned unit number 0 and devices 32 and 34 have been assigned character names $C1 and $C2, respectively.

A "logical" device is represented by a device description table which is attached to the operating system (i.e. has a unit number or character name assigned to it) but does not have a physical device directly associated with it. Logical devices (and logical device description tables) are supported by one or more default devices (and default device description tables). Represented in FIG. 2, is a logical device description table 45 which performs a function such as duplex writing to two more storage devices (default devices 31 and 33). In this example, the logical device description table is linked to the operating system as a unit, i.e., the operating system has assigned unit number 1 to logical device description table 45. When the operating system instructs the logical device description table to write data, the logical device description table sends instructions to two different default device description tables 39 and 40. Description tables 39 and 40 write the same data to two different peripheral devices 31 and 33.

An additional type of device description table is the pseudo device description table. In FIG. 2, description tables 46, 47 and 48 are pseudo device description tables. Psuedo device description tables represent the functions responsible for the pre-processing and post-processing of data. Pseudo device description tables perform special data processing functions where the data from the system is pre-processed before it goes to a peripheral device or is post-processed as it is read from a peripheral device. Note from FIG. 2, the pre- and post-processing table functions (i.e. pseudo device description tables 46, 47 and 48) can be assigned to one or more different device description tables. These assigned device description tables can be real or logical. In FIG. 2, pseudo device description table 46 is assigned to logical device description table 45, i.e., post-processes data from logical device 45. Pseudo device description table 47 is assigned to real device description table 38 and to logical device description table 45 and pre-processes data to device 30 and logical device 45. (Note: the pre-processing of data to logical device 45 results in the pre-processing of data to devices 31 and 33). Pseudo device description table 48 is assigned to real device description table 38 and pre-processes data to, and post-processes data from, device 30.

FIG. 2 represents the system configuration that is used as an example in the following description of this embodiment or example the invention. The invention is not limited to or by this configuration.

C. Device Driver Environment

The kernel is operating system dependent, i.e., the kernel satisfies the operating system's requirements for a device driver. These requirements are known to persons of ordinary skill in the art and are typically set forth in the device driver documentation published for the operating system. The requirements are different for different operating systems. Such requirements include specific request structures and device driver headers. Some operating systems require an I/O control interface.

The requirements for specific request structure is satisfied by the environmental map of the kernel (i.e., the environmental map translates operating system requests into kernel requests that can be processed by device description tables). If the operating system requires an I/O control interface then the kernel can include an I/O control interface. The I/O control interface translates I/O control requests from the operating system or applications into an I/O control kernel request which is a special kind of kernel request that can be processed as a kernel request.

A primary requirement for MS-DOS and OS/2 device drivers is that they must have a device driver header compatible with the operating system. Device driver headers are used to create a forward-linked list of the user-installed device drivers in the system. This list of device drivers contains both block and character device drivers.

The kernel can manage a plurality of block and character devices. The kernel is able to perform this task by statically linking a set of character device driver headers that have their strategy routine and interrupt routine pointers initialized to a set of null routines. The statically linked character device driver headers also link to a single block device driver header.

The character device driver headers are initialized during the kernel initialization process if any character device description tables are defined in the configuration file (CONFIG.OAD). The block device driver header is initialized after the last of the block device description tables is loaded into computer memory. At this time it is possible to determine the number of block devices that have been specified in the configuration file. Therefore, after the block device description tables have been loaded, the block device driver header is initialized to reflect the actual number of block devices configured in the system.

Because the kernels in this embodiment of the invention were developed in the C programming language, the order of the data and code were not in conformance with the device driver requirements of the MS-DOS and OS/2 operating systems. This problem was solved by re-ordering the data and code segments in the kernel.

There is a need for a mechanism that will allow description table files to be opened and read during the kernel device driver initialization process and that will provide other initialization functions. These initialization functions are performed by initialization routines contained in the kernel initialization map.

There is also a need for a mechanism to handle low-level operating system specific operations such as memory allocation and address translation. The kernel's service map serves as this mechanism by providing service routines to the kernel and description tables. In this embodiment of the invention, the service routines are DevHlp routines.

In Unix and MS-DOS, DevHlp routines do not exist. Therefore, a set of DevHlp routines are provided in the service map of the MS-DOS and Unix kernels for use in initialization and operation. In OS/2 , the DevHlp routines are part of the OS/2 operating system. Therefore, the service map of the OS/2 kernel provides the addresses of these DevHlp routines so that they can be called when needed.

A description table is operating system independent, meaning that it can be linked to a plurality of different operating systems. The description table is linkable to the MS-DOS operating system through an MS-DOS compatible kernel. The description table is linkable to the OS/2 operating system through and OS/2 compatible kernel. The description table is linkable to the Unix operating system through a Unix compatible kernel. Etc.

A device description table for a device satisfies requirements of the device for a device driver. These requirements require that the device description table create device commands that are compatible with (i.e. supported by) the device. Different devices may have different device commands. For example, a tape drive has a "rewind" command and a CD-ROM has "open and close drawer" commands. The device command must also be in a command format compatible with the device. Other requirements may include sector sizes and layouts and block/character addressing modes or formats. The requirements of a device for a device driver are known to persons of ordinary skill in the art and are typically described in technical reference documentation published for the device.

An adapter description table for an adapter satisfies requirements of the adapter for a device driver. These requirements are also known to persons of ordinary skill in the art and are typically described in technical documentation published for the adapter. Such requirements can include the method or mode of device command issuance to a device, the method or mode of data transfer to a device, and interrupt level.

D. Global Data Structure and Data Structures

The inventive device driver includes a plurality of software modules called description tables. These description tables are device description tables and adapter description tables. The description tables are linked to each other and to the kernel through the global data structure 4 (see FIG. 1). As shown in FIG. 1, the kernel contains the global data structure. As each description table is linked to the kernel, information relevant to the description table is set into the global data structure to complete the linkage. A description table can be linked to the kernel by loading the description table into the computer's memory (e.g. random access memory) and by entering information relevant to the table into the data structure. The description tables are linked to the kernel and, therefore, are linked by the kernel to the operating system.

A sample global data structure ("GDS") is shown in FIG. 3. Each device and adapter attached to the system is represented in the global data structure of FIG. 3 as a vertical column of data fields. Each such vertical column represents the "data structure" of a device or an adapter. It is also proper to state that each such vertical column represents the data structure of a device description table or an adapter description table. The device data structure (or adapter data structure) represents the interface between the kernel and the description table of the device (or adapter). The entries to these fields are information in the form of integers, addresses, arrays or other data. Some fields are unique to the support of devices. Other fields are unique to the support of adapters. Yet other fields are common to both devices and adapters. The data structure fields shown in FIG. 3 for device data structures are identified and described in Table 1 of Section VIII. The data fields shown in FIG. 3 for adapter data structures are identified and described in Table 2 of Section VIII. If an adapter field entry has already been described in Table 1 under a field entry for device data structures the description is not repeated and reference is made to Table 1.

A device data structure has fields into which device information can be entered. Device information can be some or all of the following: device configuration information, device request support information, device memory management information, and device table operation information. An adapter data structure has fields into which adapter information can be entered. Adapter information can be some or all of the following: adapter configuration information, adapter request support information, adapter memory management information, and adapter table operation information. Information for a data structure can be any information which contributes to the linkage of the description table to the operating system, the kernel, or another description table.

In the example of FIG. 3, each data structure includes the following segments:

1. Configuration. The "configuration" segment contains configuration information. For a device, device configuration information can include information identifying the device name (e.g. NAME field), information identifying an adapter to which the device is attached (e.g. ADAPTER NUMBER field), device address information (e.g. SCSI ID and SCSI LUN fields), information identifying the kind of device (e.g. CONTROL BYTE field), information for defining pseudo device relationships (e.g. DEVICE TYPE field), information for defining logical device relationships (e.g. DEFAULT NUMBER and DEFAULT BASE fields), and other configuration information. In this embodiment of the invention, device configuration information is the information entered into the following fields:

NAME

ADAPTER NUMBER

SCSI ID

SCSI LUN

PARAMETER ADDRESS

PARAMETER FIELD

DEVICE TYPE

CONTROL BYTE

DEFAULT NUMBER

DEFAULT BASE

DEVICE ID CHECK

DEVICE ATTRIBUTE

In other embodiments of the invention, device configuration information can be some or all of the information for these fields or other information of a similar kind or which serves a similar purpose. For an adapter, the adapter configuration information can include information identifying the adapter name (e.g. NAME field), information identifying the adapter number (e.g. ADAPTER NUMBER field), adapter address information (e.g. SCSI ID field) and other configuration information. In this embodiment of the invention, adapter configuration information is the information entered into the following fields:

NAME

ADAPTER NUMBER

SCSI ID

PARAMETER ADDRESS

PARAMETER FIELD

ADAPTER IRQ LEVEL

ADAPTER DMA CHANNEL

PORT ADDRESS

NUMBER PORT ADDRESSES

BASE MEMORY ADDRESS

NUMBER MEMORY ADDRESSES

BASE BUFFER ADDRESS

NUMBER BUFFER BYTES

MEMORY MAPPED SELECTOR

In other embodiments of the invention, adapter configuration information can be some or all of the information for these fields or other information of a similar kind or which serves a similar purpose.

2. Request Support. The "request support" segment contains kernel request support information. In this embodiment of the invention, device request support information is the information entered into the following fields:

UNIT QUEUE POINTER

REQUEST POINTER

DEVICE REGISTERS

DEVHLP ADDRESS

DEVHLP RETURN

In this embodiment of the invention, the request support segment of an adapter data structure has all of these fields except for the UNIT QUEUE POINTER and REQUEST POINTER fields. Adapter request support information is the information entered into the adapter request support fields. In other embodiments of the invention, device request support information (and adapter request support information) can be some or all of the information for these fields or other information of a similar kind or which serves a similar purpose.

3. Memory Management. The "memory management" segment contains memory management information. In this embodiment of the invention, device memory management information is the information entered into the following fields:

VIRTUAL ADDRESS CODE

VIRTUAL ADDRESS DATA

PHYSICAL ADDRESS CODE

PHYSICAL ADDRESS DATA

CELL PROCESSOR ADDRESS

STATE EVENT TABLE ADDRESS

In this embodiment of the invention, the memory management segment of an adapter data structure has all of these fields plus an INTERRUPT SERVICE ROUTINE ADDRESS field. Adapter memory management information is the information entered into the adapter memory management fields. In other embodiments of the invention, device memory management information (and adapter memory management information) can be some or all of the information for these fields or other information of a similar kind or which serves a similar purpose.

4. The "table operation" segment contains table operation information. In this embodiment of the invention, device table operation information is the information entered into the following fields:

CURRENT STATE

LAST EVENT

MAX NUMBER EVENTS

MAX NUMBER STATES

ERROR

DEVICE STATUS BYTE

In this embodiment of the invention, the table operation segment of an adapter data structure has all of these fields except that an ADAPTER STATUS VARIABLE field replaces the DEVICE STATUS BYTE field. Adapter table operation information is the information entered into the adapter table operation fields. In other embodiments of this invention, device table operation information (and adapter table operation information) can be some or all of the information for these fields or other information of a similar kind or which serves a similar purpose.

Tables 1 and 2 of Section VIII describe various kinds of configuration, request support, memory management and table operation information for the above-identified device and adapter data structure fields.

A device data structure can be a real device data structure, a logical device data structure, a default device data structure, or a pseudo device data structure. In FIG. 3, the first vertical column of the global data structure is a real device data structure (for a block device) and represents the interface between the kernel 1 and device description table 38 (see FIG. 2). This real device data structure is associated with a block device (i.e. device 30 in FIG. 2) and is assigned unit number 0 from the units array (see FIG. 3) because this is the unit number assigned by the operating system to the real device (i.e. device 30). The second vertical column of the global data structure shown in FIG. 3 is a logical device data structure and represents the interface between the kernel 1 and logical device description table 45 (see FIG. 2). This logical device data structure is assigned unit number 1 from the units array (see FIG. 3) because this is the unit number assigned by the operating system to logical device 45. The third and fourth vertical columns of the global data structure of FIG. 3 are default device data structures and represent the interfaces between the kernel and default device description tables 39 and 40. Because the corresponding devices (i.e. devices 31 and 33 in FIG. 2) are default devices, unit numbers are not assigned to the devices or the default device data structures. Note, however, that the default device data structures are ordered in an ordered sequence (see FIG. 3). The fifth, sixth and seventh vertical columns of the global data structure of FIG. 3 are pseudo device data structures and represent the interfaces between the kernel 1 and pseudo device description tables 46, 47 and 48. Unit numbers are not assigned to pseudo device data structures. Note, however, that the pseudo device data structures are ordered in an ordered sequence (see FIG. 3). The eighth and ninth vertical columns of the global data structure of FIG. 3 are real device data structures (for character devices) and represent the interfaces between the kernel 1 and device description tables 37 and 41 (see FIG. 2). These real device data structures are associated with character devices (i.e. devices 32 and 34 in FIG. 2). Accordingly, character names $C1 and $C2 (see FIG. 3) are assigned to these data structures by the kernel as defined by the configuration file. The last two columns of the global data structure of FIG. 3 are adapter data structures and represent the interfaces between the kernel 1 and adapter description tables 42 and 43 (see FIG. 2). These adapter data structures are associated with adapters 35 and 36 (see FIG. 2).

As each device or adapter is identified through the configuration file (CONFIG.OAD) during initialization, an entry is placed into the units array, character array or adapter array (see FIG. 3). These entries are used by the kernel to identify each vertical column (i.e. device or adapter data structure) in the global data structure. Note from FIG. 3, however, that this does not apply to default devices and pseudo devices. Only real and logical devices are assigned entries in the unit array or character array. Default and pseudo devices are not assigned a unit or character array entry. Instead, the data structures of these device types are "ordered" as shown in FIG. 3. The ordering of the default device data structures is used by the kernel in combination with the CONTROL BYTE of the logical device data structure and DEFAULT NUMBER and DEFAULT BASE fields the default device data structures to select the appropriate default device assigned to the logical device. Activation of pseudo devices is determined by the CONTROL BYTE field and the DEVICE TYPE field.

FIG. 3 shows the linking of the selected description tables to the kernel as part of the kernel initialization process. As the kernel executes its initialization map, it reads the configuration file (CONFIG.OAD) to determine the system configuration selected by the user. As each description table file is identified by the configuration file, information is placed into the global data structure as required to support the linking of the description table. The kernel's initialization map reads the configuration file (CONFIG.OAD). For each description table identified in the configuration file, the corresponding description table file is read from library 10 and linked to the kernel by the initialization map. It should be noted that description tables are prepared as independent modules and remain as such when linked to the kernel. Communication between the description tables and the kernel is through entries in the global data structure which is the interface between the kernel and each description table. This global data structure is the table interface. The kernel's initialization map sets up these entries and uses information from the configuration file (CONFIG.OAD), the description tables and the operating system to establish entries in the global data structure.

The global data structure exists in the kernel in a blank form (i.e. there are no entries in the fields of the global data structure) when the kernel is first initialized. In this embodiment of the invention there are defined in the kernel's global data structure space for 16 real or logical device data structures, 4 pseudo device data structures, 8 default device data structures and 4 adapter data structures. Thus, this global data structure can support up to 16 real or logical device description tables or devices, 4 pseudo description tables or devices, 8 default device description tables or devices and 4 adapter description tables or adapters. It is not necessary that all available data structures be used. In this particular embodiment of the invention it is seen from FIGS. 2 and 3 that only 4 (of a possible 16) real/logical device data structures are needed (for description tables 37, 38, 41 and 45 and for real block device 30, real character devices 32 and 34 and logical device 45), that only 3 (of a possible 4) pseudo device data structures are needed (for pseudo device description tables 46, 47 and 48), that only 2 (of a possible 8) default device data structures are needed (for default device description tables 39 and 40 and for default devices 31 and 33), and that only 2 (of a possible 4) adapter data structures are needed (for adapter description tables 42 and 43 and for adapters 35 and 36). The global data structure of FIG. 3 does not show the unused and unneeded data structures, i.e., only data structures for the device and adapter description tables actually used (see FIG. 2) are shown in FIG. 3. Other embodiments of the invention can define or allocate global data structure space (i.e. data structures) for other numbers of devices and adapters.

The configuration file (CONFIG.OAD) contains records identifying the devices and adapters required or selected by the user for the system. Each record identifies a specific device or adapter. Each record of the configuration file contains the name of the device or adapter description table file that is to be loaded and linked to the kernel. The configuration file (CONFIG.OAD), is contained in library 10 together with the available kernels and description tables. In this example, the library is a directory named OAD. The description tables contain the following information. Each description table contains a data segment and a code segment. The code segment contains executable computer programs (e.g. software routines). The description table file also contains a header which contains pointers to the location of the data and code segments in the file as well as the size of the data and code segments. The initialization map of the kernel uses this header with its pointers and segment size information to load the description table into the computer memory (e.g. RAM) and to set up address pointer entries in the data structure associated with the description table. These address pointers are the addresses in the computer memory (e.g. RAM) of the locations of the code and data segments of the description table after it has been loaded into the computer memory. These address pointers are entered into the "memory management" fields of the data structure.

User configuration information which is contained in the configuration file (CONFIG.OAD) and which is entered into the global data structure provides a representation of the configuration of the user's system as shown in FIG. 2. The entries in the global data structure of FIG. 3 correspond to the specific configuration map shown in FIG. 2. The user's configuration data is contained in the configuration file (CONFIG.OAD) which is used by the kernel to provided entries into the global data structure. As in the example of FIG. 3, the configuration file (CONFIG.OAD) contains the names of the devices and adapters to be used. The information from the configuration file (CONFIG.OAD) is entered by the initialization map into the global data structure as part of the kernel initialization process. The configuration file (CONFIG.OAD) provides information to the initialization map for initialization of the kernel. Configuration file information is entered into the data structure fields to which the arrows extending from the "Initialization Entries" bar point as shown in FIG. 3.

E. Device Description Tables, Adapter Description Tables and Adapter Requests

A device description table can process a kernel request issued by the kernel. A device description table can have an action list of action routines (sometimes referred to as device action routines) and a means for selecting an action routine from the action list in response to the kernel request. The selected action routine can be executed by the digital computer to cause an action routine function (sometimes referred to as a device action routine function). One kind of action routine function is the creation of an adapter request. Although a single action routine can create an adapter request it is possible to use a plurality of action routines to create an adapter request (and such plurality of action routines are deemed equivalent to such single action routine).

An adapter description table can process an adapter request. An adapter description table can have an action list of action routines (sometimes referred to as adapter action routines) and a means for selecting an action routine from the action list in response to the kernel request. The selected action routine can be executed by the digital computer to cause an action routine function (sometimes referred to as an adapter action routine function). One kind of action routine function is the issuance of a device command to a device.

As shown in FIG. 4, device and adapter description tables can be of a similar structure. Each includes a state machine cell processor (Cell Proc), a state event table and an action list of computer programs or routines. The adapter description tables (but not the device description tables) can also include an interrupt processing program (Int Proc).

A standard description table format is defined for the description tables in library 10. A standard format allows a common table interface (e.g. global data structure) to be defined between the kernel and the description tables. The standard description table format selected for a given embodiment of the invention can be selected from a wide variety of formats. The format selected for this embodiment of the invention is described below. It should be noted that in this embodiment of the invention, the description tables are developed in a subset of the ANSI standard C language, and, therefore, the file format of the description tables must be able to address the aspects of this type of compiler output.

A description table implements a state machine and includes two type of information, a code segment (computer program routines) and a data segment which contains data for the state event table. A description table is converted to a loadable description table file by concatenating a header to the description table. In addition, each of the code and data segments contain additional substructures. FIG. 11 shows the relationship between the substructures of the description table and the memory management portion of the global data structure. As also shown in FIG. 11, when the operating system operates in protected mode, a pair of selectors which are a part of the operating system's global description table (GDT), are assigned for each device or adapter description table.

As shown in FIG. 11, the description table code segment has three parts, a cell processor, an action list and an interrupt service routine. The cell processor is a state machine routine which interprets the contents of the state event table. This state machine provides a common format and structure whereby the global data structure can be used to link several independent loadable device or adapter description tables to the kernel. Associated with the cell processor is an action list which is a list or group of computer programs or routines which are referred to herein as action routines. The third portion of the description table code segment is the interrupt service routine. The interrupt service routine is part of the code segment of adapter description tables but is not included in device description tables (i.e. the code segment of device description tables only has the cell processor and action list). The interrupt service routine is executed when an interrupt for the adapter occurs.

The data segment of the description table shown in FIG. 11 contains the state event table. The state event table can be a two dimensional matrix with columns representing different events and with rows representing different states. At the intersection of each state and event is a cell which contains two entries. One entry is representative of the action that is desired. The other entry is the next state which should be used after completion of the action defined for the cell. The data segment also contains a pointer to the interrupt service routine. In particular, the data segment contains in a specific location, the offset address of the interrupt service routine in the code segment.

The memory management section of the adapter or device data structure contains addresses to different parts of the description table code and data segments. The fields of the memory management section of the global data structure are as follows.

VIRTUAL ADDRESS CODE

VIRTUAL ADDRESS DATA

PHYSICAL ADDRESS CODE

PHYSICAL ADDRESS DATA

INTERRUPT SERVICE ROUTINE ADDRESS (adapters only)

CELL PROCESSOR ADDRESS

STATE EVENT TABLE ADDRESS

Addresses for the code and data segments are contained in both virtual and physical format. The virtual format of an address is used with operating systems such as OS/2 and Unix which work in a multi-tasking protected mode. The CELL PROCESSOR ADDRESS is contained in the global data structure as a direct physical address in addition to a virtual address because the description table is not swapped in and out in a multi-tasking operating system such as OS/2 as it is part of a device driver. The addresses of the interrupt service routine and state event table are stored in the global data structure as offsets from the base addresses of the code and data segment pointers. These offsets are calculated by the initialization map based on the contents of the interrupt pointer field in the data segment and the fixed offset of the state event table from the data segment pointer based upon the fixed length of the interrupt pointer. Selectors, which are part of the operating system, are assigned to each description table and contain addresses to the code and data segments in both physical and virtual address formats.

The device description tables can operate synchronously to the operating system. The device description tables include action routines which can be executed to cause an action routine function. One such function performed by device description tables is the creation of adapter requests. Adapter requests can include device commands and adapter description table commands. Adapter description table commands define functions to be performed by the adapter description tables. When adapter requests are processed by adapter description tables, the adapter description table commands are processed and the defined functions are performed. The processing of adapter description table commands can result in the execution of action routines of the adapter description table. The execution of such action routines cause action routine functions such as the creation of adapter commands, the issuance of adapter commands to adapters and the issuance of device commands to devices. Adapter description tables can operate asynchronously to the operating system and respond to interrupts. The asynchronous operation of the adapter description tables is controlled through adapter requests.

In FIG. 1, a queue 11 of adapter requests is shown. FIG. 5 also represents this queue and provides greater detail of the structure of an adapter request by identifying the fields of an adapter request. These fields are identified and described in Table 3 of Section VIII. This adapter request structure is the adapter request structure of this embodiment or example of the invention. Other embodiments of the invention can have different structures.

The adapter request is the communication between the device description table and the associated adapter description table. The device description table is designed to accept the kernel request and then determine the appropriate sequence of operations to be performed by the adapter to accomplish the request. If it is determined that the physical device, via the adapter, must be involved in the operation, then the device description table creates the appropriate sequence of one or more adapter requests to be passed to the adapter description table for processing. The adapter requests include one or more device commands. The adapter description table issues the the device command(s) through the adapter to the device. This is depicted in FIG. 1 where a queue 11 of adapter requests is formed from the output of a device description table 8. These adapter requests are passed from queue 11 to the adapter description table 9 associated with the adapter that supports the device to which the request is directed and to which the device command is issued.

The adapter request is comprised of a plurality of fields into which information is entered. This information will be used by the adapter description table to process the adapter request. In addition, certain adapter request fields contain other information such as a device command and the address of the data buffer (see data buffer 15 in FIG. 1) when data is to be read from or written to a device. The adapter description table uses this data buffer in transferring data between computer memory and the device.

As an example, for a SCSI device, each device has a pre-defined set of SCSI Command Description Blocks (CDBs) which are suggested by the American National Standards Institute (ANSI) and published by the manufacturer of the device. ANSI gives the basic structure and suggested contents of the CDB. The manufacturer of the device gives the specific contents of the CDB for its device. The CDB is a device command.

Since the device description table is specific to a particular device, the device description table creates the CDB (i.e. the device command) as required by the device to perform the desired action. This CDB (i.e. device command) is placed by the device description table into the CDB AREA field (i.e. device command field) of the adapter request. Since the ANSI SCSI standard allows for variable length CDBs, the device description table also places the length of the CDB into the LENGTH OF CDB field of the adapter request.

The adapter description table does not modify or use the contents (i.e. device command) of the CDB AREA field of the adapter request. Instead, the adapter description table passes (i.e. issues) the contents (i.e. device command) of the CDB AREA field directly to the device. This removes device specific actions from the adapter description table. Thus, the adapter description table can be used with a plurality of different devices. Conversely, since the adapter description table does not modify or use the contents of the CDB AREA field, a single device description table can be used with a plurality of different adapter description tables. Thus the "mix and match" capability of this invention between devices and adapters is achieved. The CDB AREA field for a non-SCSI device, such as an ESDI device, will contain a device command required for and compatible with the ESDI device. The adapter description table does not modify or use the contents of this field except to issue it to the device through the adapter.

The operating system request and the kernel request indicate the device to which the request is directed. The device description table creates an adapter request in response to the kernel request. The adapter request contains device specific information but no adapter specific information. The kernel selects the adapter description table to which the adapter request is sent by referring to the ADAPTER NUMBER field of the device data structure for the indicated device. For example, if device 30 is indicated by the operating system, then the kernel refers to the ADAPTER NUMBER field of device 30's device data structure which is represented by the first vertical column in the global data structure of FIG. 3. The entry in the ADAPTER NUMBER field is 1. With this information, the kernel selects adapter description table 42 because the adapter data structure associated with adapter description table 42 also has 1 as the entry in its ADAPTER NUMBER field (see the tenth vertical column of the global data structure of FIG. 3). Adapters and adapter description tables are numbered in the adapter array. As part of the initialization process the appropriate number for a given adapter (and adapter description table) is entered from the configuration file (CONFIG.OAD) into the ADAPTER NUMBER field of the adapter data structure associated with the adapter (and the adapter description table). For each physical device associated with an adapter (in this example devices 30, 31, 32, 33 and 34) the ADAPTER NUMBER field of the device data structure associated with the device (and with the device's description table) has an entry which indicates the adapter number of the adapter (and adapter description table) associated with the device. As part of the initialization process the appropriate adapter number for a given device (and device description table) is entered from the configuration file (CONFIG.OAD) into the ADAPTER NUMBER field of the device data structure associated with the device (and the device description table). As described above, an adapter request is an output from a device description table. The adapter request is sent to the adapter description table indicated by the device data structure associated with the device description table from which the adapter table request packet was sent.

This strategy allows a device description table to be used with a plurality of different adapter description tables, i.e., the configuration file for one configuration can associate the device description table with one adapter description table and a different configuration file for a different configuration can associate the device description table with a different adapter description table. Thus it is not necessary to create a different device description table for each adapter or adapter description table. This strategy also allows a single adapter description table to support a plurality of device description tables. Thus, the user can combine into the user's system configuration a selection of device description tables and adapter description tables as needed to support the user's physical devices and adapters.

The adapter description table requires no device specific information from the adapter request, thus the adapter description table is device independent and can function with a plurality of different devices. The adapter description table passes the device command (i.e., contents of the CDB AREA field) directly through the adapter to the physical device. The device description table creates the adapter request in an independent manner and thus a single device description table can be used with a plurality of adapter description tables in different configurations. A plurality of device description tables can be used with each of a plurality of adapter description tables allowing various combinations to be used and selected by the user. In addition, a plurality of device description tables can create adapter requests for a single adapter description table thus providing for the functioning of a plurality of devices on a single adapter. The configuration file (CONFIG.OAD) defines which device description tables are connected through the global data structure to each adapter description table.

F. Initialization Map and Initialization Routines

The initialization map is a means for providing initialization routines to the kernel that are needed for initialization (loading) of the inventive device driver. In this embodiment of the invention, five OS/2 API calls or routines (Application Programming Interface calls or routines) are used as initialization routines. Because these API calls are included in the OS/2 operating system, the initialization routines of the OS/2 kernel's initialization map are routines which, when executed, call the needed API call in the OS/2 operating system. For other operating systems, such as MS-DOS and Unix, which do not have these API calls, the API calls are included in the initialization map as the initialization routines. The initialization routines (or API calls) are as follows:

DosRead

DosClose

DosOpen

DosChgFilePtr

DosPutMessage

A more complete discussion of the OS/2 Application Programming Interface (API) and the API calls is presented in the OS/2 Technical Reference Manual available from Microsoft Corporation.

The initialization routines are used during device driver initialization time. Since the kernel is the portion of device driver responding to initialization commands from the operating system, only the kernel needs to have access to the initialization routines. The description tables do not utilize any of the initialization routines because the description tables are not executed until after the device driver initialization process is complete.

G. Initializing and Loading

The initialization and loading of the inventive device driver begins with the existence of a library of kernels, device description tables and adapter description tables. The user creates a configuration file (CONFIG.OAD) which identifies the device description tables and adapter description tables needed to support the devices and adapters of the system configuration selected by the user. The configuration file also provides additional configuration information. Configuration information from the configuration file is entered into the global data structure. The configuration file is comprised of configuration records for the devices and adapters selected. The fields or contents of a configuration record are shown on Table 5 in Section VIII. The configuration file also contains installation specific information such as the device address (e.g. SCSI ID and SCSI LUN fields) assigned to each device and the interconnection of real, logical, default and pseudo devices (e.g. DEVICE TYPE, CONTROL BYTE, DEFAULT NUMBER and DEFAULT BASE fields).

The initialization of the inventive device driver is preceded by the normal operating system procedure of loading a device driver through a system configuration file which for MS-DOS and OS/2 is the CONFIG.SYS file. This file is recognized by the operating system. The standard OS/2 and MS-DOS method of defining an external device driver is to use a DEVICE=XXX.SYS statement in the CONFIG.SYS file. In this example, XXX.SYS is the name of a kernel and so the statement may read DEVICE=KERNEL1.SYS.

The kernel meets the requirements of a loadable device driver. A kernel is created for each needed or selected operating system. Thus the specific device driver requirements of an operating system are met by the kernel created for that operating system. For some operating systems such as Unix which do not support loadable external device drivers, the kernel can be linked to the operating system. The linked combination is then loaded into computer memory. Either way, the kernel (separately or in combination with the operating system) is loaded into computer memory.

After the kernel is loaded by (or with) the operating system, the initialization process and the active role of the kernel begin. As part of the loading of a device driver, the operating system issues an initialization command to the device driver. In this case, the operating system issues an initialization command to the kernel. This initialization command causes initialization routines in the initialization map of kernel to execute and control the remaining part of the kernel initialization process. The initialization process begins with the operating system issuing an initialize (INIT) command to the kernel by sending an initialize command request block to the kernel. This command initiates the following sequence of events which are summarized by the flow chart in FIG. 9.

The kernel displays on the computer screen an introductory message "OAD Device Driver Initialization". This message is displayed using the DosPutMessage API call. Following the display of this message the kernel initializes the DevHlp routine pointer to the DevHlp routine address contained in the initialize command request block.

Conventionally, the operating system requires a BIOS Parameter Block (BPB) for each block device attached through a device driver. However, at this stage in the initialization process the inventive device driver does have the BPBs because the device description tables have not yet been loaded. Therefore, the kernel generates BPBs in a number equal to the maximum number of devices which can be supported by the kernel. The kernel generates BPBs by initializing an array data structure of BPBs. The contents of the BPB data structure are temporary and are replaced by device-specific contents from the device description table when it is loaded. Each loaded block device description table requires the use of a BPB to describe the device's characteristics. The temporary data contents of the BPB are replaced by device-specific information from the device description table. This is in accordance with the operating system requirements for a device driver which the kernel must satisfy to be a valid device driver. Table 4 of Section VIII sets forth a C data structure which identifies the contents of a block device BPB.

After completing the above steps, the initialization process enters the dynamic loading phase of its execution. This phase begins with an attempt to open, via the DosOpen initialization routine, the configuration file (CONFIG.OAD). If the open fails then an error message is displayed and the kernel returns an error condition to the operating environment.

The configuration file (CONFIG.OAD) is comprised of a plurality of configuration records with one record for each device or adapter description table that has been selected for loading. Once the configuration file (CONFIG.OAD) is opened, the configuration records are read from the file, via the DosRead initialization routine. The fields of the configuration record are specified by the C data structure set forth in Table 5 of Section VIII. Some of the fields are only applicable to adapter description tables, some fields are only applicable to device description tables and some fields of the configuration record are common to both device and adapter description tables. The first field, INI.sub.-- rec.sub.-- type is used to identify the type of description table (i.e. device or adapter) loaded and is not loaded into the global data structure. Other entries in the configuration fields are entered into the fields of the global data structure. Each configuration record field (except INI.sub.-- rec.sub.-- type) has a corresponding global data structure field into which the contents of the configuration record field is entered. As an example, the entry in the INI.sub.-- irq.sub.-- data field is entered into the ADAPTER IRQ LEVEL field of the adapter data structure in FIG. 3.

Configuration records contain the information necessary to configure the device driver for execution. The configuration record contains the name of the description table (INI.sub.-- NAME) that is to be loaded and linked to the kernel.

If the configuration record is an adapter record, then the information necessary to configure the adapter is included in the configuration record. This information includes the differences between memory-mapped adapters and Port-I/O adapters.

If the configuration record is a device record then information concerning the physical connection of the device to an adapter is included in the configuration record. This information includes the type and identification of the device.

Normally there is a separate description table for each device or adapter in the system configuration. However, if the system configuration includes two or more devices of the same kind (or two or more adapters of the same kind), then a single description table can be shared by such devices (or adapters). Sharing can be based on a common NAME or on a common DEVICE TYPE as defined in the configuration record and the global data structure. The configuration record has a fixed field (INI.sub.-- rec.sub.-- type) that controls the type of configuration record (i.e. device or adapter) and controls the type of description table usage (i.e. shared or nonshared). This fixed field (INI.sub.-- rec.sub.-- type) determines which one of the following four types of usage is applicable:

1. Adapter Description Table (non-shared)

2. Device Description Table (non-shared)

3. NAMEd File (sharing of description table determined by common contents of the NAME field)

4. TYPED File (sharing of description table determined by common contents of the DEVICE TYPE field)

The most common usages are nonshared uses of device description tables and adapter description tables. However, sharing based on a common NAME or a common DEVICE TYPE can also be used.

A NAMEd file is used after a description table has already been linked to the kernel as a non-shared description table. This non-shared description table has been loaded into memory and its memory address pointers have been entered into the data structure of the device or adapter. When a subsequent configuration record is read and if the INI.sub.-- rec.sub.-- type field indicates a NAMEd file, a search is made by the kernel's initialization map to locate a data structure (a vertical column in the global data structure of FIG. 3) having a NAME field whose entry matches the entry in the INI.sub.-- NAME field of the configuration record. When this already loaded device description table is found then the information pertaining to the address of the code and data for that previously loaded description table is copied to the appropriate device or adapter data structure of the description table being loaded (i.e. the description table having the NAMEd file). An additional copy of the description table is not loaded into memory, however, configuration information such as the ADAPTER NUMBER and other field entries are loaded from the configuration file CONFIG.OAD into the device data structure for the new device or adaptor which shares the description table. The contents of the data structure for the new device or adapter thus contains configuration information for the new device or adapter and address information for the previously loaded description table.

Typically, the use of NAMEd File sharing of a previously loaded description table allows a device to be identified using only the field in the data structure (which in this example requires less than 512 bytes) rather than loading a duplicate description table (which in this example may require more than 4,000 bytes).

In the example of FIG. 3, the device B1 description table is loaded only once. Two data structures (represented in FIG. 3 as two vertical columns) in the global data structure are used to allow two devices B1 to be used as a real device and a default device. This allows a shared description table to be used in two different ways--e.g., as a real device and as a default device supporting a logical device. This type of description table is a shared device description table. In other words, the only size penalty that is incurred by utilizing the NAMEd file is the overhead of a device data structure that is typically less than 512 bytes.

The advantages of utilizing NAMEd files in a memory constrained environment, such as MS-DOS, can be beneficial. In a more memory liberal environment it is suggested that NAMEd files not be used, but rather that the device description tables be defined as separately loaded description tables to obtain optimum device description table protection and physical memory separation.

Typed Files are analogous to NAMEd Files. However, the location of the search for the previously loaded description table is limited to the default device description table entries in the global data structure. The file matching algorithm is also different. Rather than matching the contents of the NAME fields of the global data structure, a Typed file matches the contents of the DEVICE TYPE fields. The DEVICE TYPE specified in the configuration record is matched with the DEVICE TYPE fields specified in the data structures of the currently loaded default description tables. Where the match occurs, entries are transferred from the configuration record of the configuration file CONFIG.OAD into the fields of the new data structure for the new device but a duplicate copy of the description table is not loaded. Memory addresses for the previously loaded description table are copied into the memory address fields of the new device data structure.

The way in which a Typed file is loaded is as follows. The user specifies in the configuration record that this entry is a Typed file description table. This implies that the user has also provided in the configuration record a DEVICE TYPE value in the INI type field. As the particular configuration record is being processed configuration entries are made into the device data structure for this description table.

Finally, a search is made through all of the previously loaded default devices to determine if the contents of the DEVICE TYPE fields of the configuration record and a default device description table match. If a match is found then the information pertaining to the memory location of the previously loaded default device description table is copied into the typed file's device data structure.

In summary, a Typed file is simply another method of implementing the concept of shared device description tables.

The following is a more descriptive example of the initialization and loading of description tables. This example identifies specific initialization routines (API calls) and service routines (DevHlp routines) that are used.

The configuration record as contained in the configuration file (CONFIG.0AD) contains the name (INI.sub.-- NAME) of a description table file. The initialization map uses this name to locate within the library the description table file having the same name. The library contains the loadable description table files. This library also contains the available kernels and the configuration file.

A DosOpen initialization routine (API call) is issued by the initialization map to open the description table file. Once the description table file is opened, a DosRead initialization routine (API call) is issued by the initialization map to read the information contained in the header of the description table file. This information contains the length of the code and data segments both in the description table file and in the computer memory after loading has occurred.

From the information contained in the header, the following six variables are extracted. See FIG. 11.

1. Code Segment Pointer to Code in Description Table File

2. Code Segment Length in Description Table File

3. Code Segment Length in Computer Memory

4. Data Segment Pointer to Data in Description Table File

5. Data Segment Length in Description Table File

6. Data Segment Length in Computer Memory

After the information from the description table header has been read by the initialization map, the actual description table file loading process begins. The description table file is loaded in two parts. First, the code segment of the description table file is loaded into computer memory. Then the data segment of the description table file is loaded into computer memory. The following paragraphs describe the operations performed in the loading process.

First, an AllocPhys service map DevHlp routine call is made by the kernel through its initialization map to allocate the amount of physical memory required to load the code segment into computer memory. The result of the AllocPhys call is a physical 32-bit address that is saved in the PHYSICAL ADDRESS CODE field of the data structure (see FIG. 3) associated with the description table being loaded.

Second, a PhysToVirt service map DevHlp routine call is made by the kernel through its initialization map to convert the physical address returned from the AllocPhys call into a usable virtual address. The result of the PhysToVirt call is a 32-bit virtual address that is stored in the VIRTUAL ADDRESS CODE field of the data structure associated with the description table being loaded.

Third, a DosChgFilePtr service map DevHlp routine call is made by the kernel through its initialization map to position the file pointer to the appropriate location in the file where the code segments begins.

Fourth, a series of DosRead initialization routine calls are made by the kernel through its initialization map to read the code segment from the description table file into the physical memory just allocated. This process of reading the code segment from the description table file continues until all of the code has been read.

Fifth, an UnPhysToVirt DevHlp service map routine call is made by the kernel through its initialization map to release the virtual address that was allocated in order to read the code from the description table file into the physical memory previously allocated.

Sixth, an AllocateGDTSel service map DevHlp routine call is made by the kernel through the initialization map to allocate a global descriptor table (GDT) selector to the description table file in computer memory. This selector is equivalent to a virtual address such as the address obtained from the PhysToVirt call previously used. However, the AllocateGDTSel call is intended to allocate a virtual address for use until the system is rebooted, whereas the PhysToVirt call is intended for short-term virtual address operations. The result of the AllocateGDTSel call is a selector/segment entry that is entered into the VIRTUAL ADDRESS CODE field of the data structure which replaces the entry for the PhysToVirt address of the second step.

Finally, a PhysToGDTSel service map DevHlp routine call is made by the kernel through its initialization map to initialize the allocated selector (VIRTUAL ADDRESS CODE) to the physical memory location (PHYSICAL ADDRESS CODE) previously allocated.

Once the code segment has been loaded into memory then the data segment is loaded. The following describes the loading process required to load the data into physical memory.

First, an AllocPhys service map DevHlp routine call is made by the kernel through its initialization map to allocate the amount of physical memory required to load the data segment into the computer memory. The result of the AllocPhys call is a physical 32-bit address that is saved in the PHYSICAL ADDRESS DATA field of the data structure of the description table being loaded.

Second, a PhysToVirt service map DevHlp routine call is made by the kernel through its initialization map to convert the physical address returned from the AllocPhys call into a usable virtual address. The result of the PhysToVirt call is a 32-bit virtual address that is stored in the VIRTUAL ADDRESS DATA field of the data structure associated with the description table being loaded.

Third, a DosChgFilePtr service map DevHlp routine call is made by the kernel through its initialization map to position the file pointer to the appropriate location in the file where the data segment begins.

Fourth, a series of DosRead initialization routine calls is made by the kernel through its initialization map to read the data segment from the description table file into the physical memory just allocated. This process of reading the data segment from the description table file continues until all of the data has been read.

Fifth, an UnPhysToVirt service map DevHlp routine call is made by the kernel through its initialization map to release the virtual address that was allocated in order to read the data from the file into the physical memory previously allocated.

Sixth, an AllocateGDTSel service map DevHlp routine call is made by the kernel through its initialization map to allocate a global descriptor table (GDT) selector to the description table file in computer memory. This selector is equivalent to a virtual address such as the address obtained from the PhysToVirt call previously used. However, the AllocateGDTSel call is intended to allocate a virtual address for use until the system is rebooted, whereas the PhysToVirt call is intended for short-term virtual address operations. The result of the AllocateGDTSel call is a selector/segment entry that is entered into the VIRTUAL ADDRESS DATA field of the data structure for the PhysToVirt address of the second step.

Finally, a PhysToGDTSel service map DevHlp routine call is made by the kernel through its initialization map to initialize the allocated selector (VIRTUAL ADDRESS DATA) to the physical memory location (PHYSICAL ADDRESS DATA) previously allocated.

If at anytime the loading process fails then all allocated memory and selectors are returned to the system. Once the resources are returned to the system then an appropriate error message is issued by the kernel through its initialization map and the initialization terminates.

H. Protected Mode of Operation

A description table can operate in protected mode when the processor and operating system support protected mode. If protected mode is not supported (e.g. MS-DOS) then the kernel simulates protected mode as much as possible. Protected mode ensures that each description table is independent of other description tables and cannot interfere with other portions of the operating system or other programs or data. Protected mode uses virtual addresses which in general do not have a constant mapping to a physical memory address. In a protected mode system, application programs operate only using virtual addresses. Device drivers and other hardware oriented programs require a knowledge of the corresponding physical address associated with the virtual address. Address pointers to loaded description tables in the global data structure require access to both virtual and physical addresses.

In order to ensure the integrity of the description table, both the data and code segments of the description table operate at level 3, protected mode, of the operating system. The kernel operates at level 0, an unprotected mode. The data segment is restricted to a read/write mode while the code segment is restricted to a read/write/execute mode. Any description table or other program in the system that attempts to use these memory segments in a mode other than defined will create a memory violation error. In addition, the protected mode of the computer assigns specific memory segments to the code and data segments. Any attempt from the software operating in the description table to access data outside of the boundaries of the defined memory segment will also create a system error condition. The protection of memory allocation and the authorization level insure that each description table operates independently of other description tables and applications in the system.

The OS/2 and Unix operating systems use protected mode and allow virtual addressing. MS-DOS does not use protected mode or allow virtual addressing. Therefore, the MS-DOS kernel emulates virtual addresses by equating virtual addresses to physical addresses. For OS/2 , Unix and other operating systems that use protected mode, virtual addresses for each section of memory are contained in selectors which are part of the global description table (GDT) of the operating system. A selector must be set up for the physical and virtual addresses and modes of access for the description table to operate correctly with the kernel. These operating systems do not allow for the setting of GDT selector mode entries to Read/Write/Execute mode as required by the code segment of the description table. For each description table there are two GDT selectors (see FIG. 10). One selector for code segment and one selector for data segment. Each selector is assigned a mode of access by the operating system. A mode of access means Read/Write/Execute mode, Read/Write mode, Read mode, etc. The code segment requires a Read/Write/Execute mode but the operating system does not permit this during initialization. Therefore, during initialization the access mode is set to a permitted mode (e.g. Read/Write). To provide for the setting of the selector entries in the global description table to Read/Write/Execute as required, a flag is set when the first record of the configuration file (CONFIG.OAD) is read. After setting this flag, the kernel continues to read consecutive records from the configuration file (CONFIG.OAD), attaching description tables and setting the selector mode to Read/Write. This process continues until the last record is read. The kernel returns control to the operating system and kernel initialization is complete. When the first operating system request is received by the kernel, the flag is interrogated. If the flag is set, the kernel will loop through the selectors and change the selector mode for each description table code segment to Read/Write/Execute. The flag is set to a state indicating that selector mode change is no longer needed. This process allows each of the description tables to operate in protected mode if the operating system allows protected mode operation.

This process of setting up the selectors in the global description table allows each of the description tables to operate in protected mode. Protected mode ensures that the description table will not interfere with other programs or data in computer memory (e.g. RAM). The kernel, being a device driver, must operate in an unprotected mode and as such has access to all sections of computer memory. This linkage of an unprotected mode kernel to protected mode adapter and device description tables is accomplished by the kernel setting the selectors for each description table to the proper Read/Write/Execute mode after initialization and by setting up the required memory addresses (both physical and virtual addresses) in the global description table and in the global data structure. As a result, the operating system and the computer monitor the operation of each description table. If the routines in the adapter or device description tables try to access memory in a mode other than Read/Write/Execute for code or Read/Write for data or tries to access a section of memory that is not allocated to the description table, the operating system detects a memory access violation error and stops the system. This process helps ensure the independence of the adapter and device description tables and allows them to be combined in different combinations and to operate in a reliable manner. If a programming error exists in a description table, the operating system will not allow this error to cause undetected errors in other description tables or other programs or data. Instead the system will stop and the error can be fixed to ensure reliable operation.

MS-DOS does not support a protected mode of operation. In this case, the memory management functions required by the adapter and device description tables are simulated through the environmental map of the MS-DOS kernel. Isolation of description tables is maintained (to the extent possible) even in the MS-DOS kernel by using independent computer register values for each or description table. In this case a register set is stored in computer memory for each description table and is used only by that table. Thus problems which can occur from sharing register sets are minimized.

At the completion of the initialization and loading process, system memory is set up as shown in FIG. 10. The file loader is used to read configuration records from the configuration file (CONFIG.OAD) if the operating system does not provide this support. If the operating system does not provide this support (i.e. if the kernel cannot access the operating system's file loader), then a file loader must be provided as part of the kernel's initialization map. An accessible file loader is provided in the OS/2 operating system. However, a file loader must be provided as part of the initialization map of an MS-DOS kernel. At the completion of initialization, linked to the kernel and included as part of the assembled device driver are the device and adapter description tables. The operating system global description table (GDT) is set up with the description table code segments set for Read/Write/Execute with references to each of the code and data segments of the description tables. Data segments are set up in a Read/Write mode.

I. Service Map and Pointers

The kernel, device description tables and adapter description tables require access to operating system functions such as memory management, physical to virtual memory address mappings, etc. Some operating systems, such as OS/2 , provide direct access to these functions. Others, such as MS-DOS, do not use or provide access to these functions. The service map of the invention provides a means whereby the kernel and description tables can have access to a common set of service routines (i.e. the service map provides service routines to the kernel and description tables). In this example or embodiment of the invention, the service routines of the service map are referred to as DevHlp routines (because certain OS/2 DevHlp routines were selected as a model set of service routines). Each kernel in library 10 uses the same set of service routines or DevHlp routines in the service map of each kernel. DevHlp routines are numerically indexed. The kernel and the description tables call or reference DevHlp routines through this index.

An example operation of the service map is shown in FIG. 8. The service map contains a service pointer map referred to as a DevHlp pointer map. The service map map also contains service routines, e.g., DevH1p routines. The address of each of these DevHlp routines is contained in its associated entry in the DevH1p pointer map. Thus, DevH1p pointer map position 0, has the address of DevH1p routine 0. DevH1p pointer map position 1 has the address of DevH1p routine 1, and so on.

The DOS and Unix kernel service maps implement the desired DevHlp routine directly (i.e. these service routines are part of the kernel's service map). Since OS/2 provides a device driver access to OS/2 's DevHlp routines, the DevHlp routines are contained in the OS/2 operating system (i.e. the OS/2 kernel's service map does not contain the DevHlp routines but does contain a means for calling or accessing the DevHlp routines in the OS/2 operating system).

The service map is accessed by the kernel and the description tables using the DEVHLP ADDRESS field of the global data structure. This DEVHLP ADDRESS field contains the address of the DevHlp pointer map (a service routine pointer map) which is contained in the kernel service map. As an example, when a description table needs DevHlp routine 1, the description table uses the address of the DevHlp pointer map contained in the DEVHLP ADDRESS field of the description table's data structure as a base address. To this base address, an index offset of 1 is added which points to the address of entry 1 in the DevHlp pointer map. Entry 1 is the address of DevHlp routine 1. The description table uses the contents of entry 1 to call DevHlp routine 1. The called DevHlp routine is executed and provides the function required by the description table.

When the DevHlp routine has completed its function, it returns control to the description table. The service map DevHlp routines are the same for the MS-DOS kernel, OS/2 kernel and Unix kernel (and any other kernels for other operating systems) in library 10. The implementations are different, however. The MS-DOS and Unix kernel service maps include the DevHlp routines. The OS/2 kernel service map uses the DevHlp routines which are contained in the OS/2 operating system. The address to the DevHlp pointer map is contained in the DEVHLP ADDRESS field of the global data structure. The DevHlp pointer map has the addresses to the DevHlp routines. Thus, the description table has a means of addressing (and, therefore, accessing or calling) a service map which provides service routines (DevHlp routines) which are common to all of the kernels in library 10.

Some operating systems may implement directly only a portion of the DevHlp routines needed by the description tables or the kernel. The kernel service map for these operating systems will then activate the DevHlp routine, e.g., DevHlp 33 as shown in FIG. 8, in a manner similar to the service map for OS/2 . In this example, DevHlp routine 33 calls the DevHlp function contained in the operating system. Other DevHlp routines, (Routines 0, 1, 2, 3 in the example of FIG. 8) are implemented directly in the service map in a manner similar to the service maps of MS-DOS and Unix.

The inventive device driver does not necessarily utilize all of the OS/2 DevHlp routines, The following list indicates the DevHlp routines that are employed within the kernel as service map routines in this embodiment of the invention. These are a subset of the OS/2 DevHlp routines.

AllocateGDTSel

AllocPhys

FreePhys

PhysToGDTSel

PhysToVirt

Run

SetIRQ

UnPhysToVirt

J. Operation of the Invention

The invention provides support for devices and adapters, This support is partitioned into the following functional areas as shown in FIG. 6:

1. Pre-processing functions (pre-process pseudo device description tables)

2. Device specific translation (device description tables, including real, logical and default device description tables but not including pseudo device description tables)

3. Adapter specific translation (adapter description tables)

4. Post-processing functions (post-process pseudo device description tables.)

FIG. 12 shows an overview description of relationships between the different types of device description cables and adapter description tables. Each description table is implemented using a state machine model. The description tables operate in a sequence defined by the contents of the global data structure as controlled by a sequencer. The sequencer is a means for sequencing the operation of the description tables. The sequencer is a computer program and is part of the kernel.

The operation of the inventive device driver begins with the operating system creating a request as shown in FIG. 12. This operating system request is translated to a common kernel request by the environmental map. This translation can be any means for creating the appropriate kernel request in response to the operating system request. Some operating system requests may be translated into more than one kernel request. The sequencer, upon receiving the kernel request, loops through the pseudo device description tables identified as pre-processors in the CONTROL BYTE field of the global data structure. The sequencer activates, in an ordered sequence, each pseudo device description table which has been specified as a pre-processing pseudo device description table in its CONTROL BYTE field (see global data structure in FIG. 3). The ordered sequence is the order of psuedo devices defined in the global data structure (see FIG. 3). The order in which pseudo device description tables are linked is determined by the order in which the pseudo device description tables are linked to the kernel. This order is determined or defined by the configuration file. The operations shown in FIG. 12 represent the configuration of FIG. 2 for the processing of Logical Device DU (device 45). The kernel request is received by the sequencer in the form of a request block. The address of the request block is placed by the sequencer into the REQUEST POINTER field of the data structure of Logical Device DU. Thus, the Logical Device DU description table has access to the complete request block and all information contained within the block. As shown in FIG. 3, the data structure associated with Logical Device DU has a DEVICE TYPE defined as 81. The sequencer places into the UNIT QUEUE POINTER field of the pseudo device's data structure a pointer to Logical Device DU's data structure. Using its UNIT QUEUE POINTER, the Pseudo Device P1 description table interrogates the DEVICE TYPE field of Logical Device DU, finds the field equal to 81 and proceeds to pre-process the data in the data buffer (which can be, for example, data in the application's buffer space or in any other buffer space). The DEVICE TYPEs for which the pseudo device description table will process (e.g. 80, 81, etc.) are programmed into the pseudo device description table. The Pseudo Device P1 description table is programmed to process device type 81. Upon completion of this processing, the Pseudo Device P1 description table, creates an Exit State Machine control event and passes control back to the sequencer. This control event is an action routine function. The sequencer loops to the next pseudo device description table that is set for pre-processing in its CONTROL BYTE. Note that Pseudo Device P2 is by-passed because its CONTROL BYTE is not set for pre-processing (it is set for post-processing only). Pseudo Device P3 is the next pseudo device set for pre-processing. However, the Pseudo Device P3 description table is programmed to process DEVICE TYPE 80. This DEVICE TYPE does not match the 81 set for Logical Device DU. Therefore, the Pseudo Device P3 description table does not process the data in the data buffer. The Pseudo Device P3 description table creates an Exit State Machine control event and passes control back to the sequencer.

The sequencer next accesses the Logical Device DU description table because Logical Device DU is the target of the operating system request and kernel request. Control is passed to the Logical Device DU description table. It is programmed to create an Invoke Default Device control event which causes control to be passed back to the sequencer. This control event is an action routine function. Logical Device DU has invoked a default device description table. Note, that in this example, the logical device description table invokes the default device description table through the sequencer. It is possible for a logical device description table to invoke the default device description table in other ways, for example by a direct call to the default device description table.

The sequencer interrogates the contents of the DEFAULT BASE field of the data structure associated with Logical Device DU. This field contains a 0 which indicates control is to be passed to the 0'th (first) default device. This default device is Device B1. The sequencer passes control to the Device B1 description table. The Device B1 description table creates an adapter request (including a device command for Default Device B2) and creates an Execute Adapter control event and passes control back to the sequencer. The sequencer interrogates the ADAPTER NUMBER field of the data structure associated with Default Device B1 and finds Adapter 1 is attached to Default Device B1. The sequencer passes control to the Adapter 1 description table.

The Adapter 1 description table then issues the device command by addressing registers in the adapter itself through the system hardware interface. These registers in turn transfer information and control via the SCSI interface (or other device interface) to the registers of Device B1. After setting up Default Device B1 for a data transfer, the Adapter 1 description table places Default Device B1 into a data transfer phase. In this example, a duplex write is to take place. Therefore, data is written from the data buffer into Default Device B1.

Upon completion of the writing of data from the data buffer to Default Device B1, control is passed back to the Adapter 1 description table from Adapter 1. The Adapter 1 description table creates an Exit State Machine control event and passes control back to the sequencer. The sequencer, detecting the Exit State Machine control event from the Adapter 1 description table, passes control back to the Default Device B1 description table. Default Device B1 description table creates an Exit State Machine control event and passes control back to the sequencer. The sequencer detecting the Exit State Machine control event passes control back to Logical Device DU. Logical Device DU, then creates an Invoke Default Device control event and passes control back to the sequencer. The sequencer keeps track of the number of passes through the default devices. Since this is the second pass, the sequencer adds one to the DEFAULT BASE field in the device data structure associated with Logical Device DU. The sequencer then passes control to the next default device description table in accordance with the ordered sequence in the global data structure and the DEFAULT BASE field of Logical Device DU. The next default device description table is the Default Device B2 description table. This activates the Default Device B2 description table.

The sequencer passes control to the Default Device B2 description table. The Default Device B2 description table creates an adapter request (including a device command for Default Device B2) and creates an Execute Adapter control event and passes control back to the sequencer. The sequencer interrogates the ADAPTER NUMBER field of the data structure associated with Default Device B2 and finds Adapter 2 is attached to Default Device B2. The sequencer passes control to the Adapter 2 description table.

The Adapter 2 description table then issues the device command by addressing registers in the adapter itself through the system hardware interface. These registers in turn transfer information and control via the SCSI interface (or other device interface) to the registers of Default Device B2. After setting up Default Device B2 for a data transfer, the Adapter 2 description table places Default Device B2 into a data transfer phase. In this example, a second duplex write is to take place. Therefore, the same data is written from the data buffer into Default Device B2 as was previously written into Default Device B1.

Upon completion of the writing of data from the data buffer to Default Device B2, control is passed back to the Adapter 2 description table from Adapter 2.

The Adapter 2 description table creates an Exit State Machine control event and control is passed to the sequencer. The sequencer returns control to the Default Device B2 description table. The Default Device B2 description table also creates an Exit State Machine control event which returns control to the sequencer. The sequencer returns control to the Logical Device DU description table. The Logical Device description table also creates an Exit State Machine control event which returns control to the sequencer.

The sequencer then activates, in an ordered sequence, each pseudo device description table that is set for post-processing in its CONTROL BYTE field. Control is passed by the sequencer to the Pseudo Device P2 description table which is the first post-processing description table in the ordered sequence. The Pseudo Device P2 description table interrogates the value of the DEVICE TYPE field of the data structure of Logical Device DU and the device type value programmed into the Pseudo Device P2 description table. Each of these values is 81. Post-processing by the Pseudo Device P2 description table of data in the data buffer then takes place. Upon completion of processing of data in the data buffer, the Pseudo Device P2 description table creates an Exit State Machine control event and passes control back to the sequencer. The sequencer then passes control to the Pseudo Device P3 description table which finds that the value (81) of the DEVICE TYPE field associated with Logical Device DU does not match the device type value (80) programmed into the Pseudo Device P3 description table. Therefore, the Pseudo Device P3 description table does not post-process data in the data buffer. The Pseudo Device P3 description table creates an Exit State Machine control event and passes control back to the sequencer.

Since Pseudo Device P3 is the last pseudo device with entries found in the global data structure, the sequencer, using the contents of Logical Device DU's ERROR field, creates an error (return) response to the environmental map. This error response is translated by the environmental map into the required Operating System error response. Normally a "0" error response indicates a successful completion. This completes the device driver's response to the operating system request.

A more detailed description of the operation of the inventive device driver is shown in FIG. 6. The operating system creates an operating system request. A list of OS/2 operating system requests is shown in Table 6 of Section VIII. Table 8 of Section VIII is a list of MS-DOS operating system requests. Other operating systems have their own lists of operating system requests. These operating system requests are translated using the environmental map of the kernel into kernel requests which are presented to the sequencer. The sequencer activates and sequences the description tables. The sequencer provides overall coordination between the functions of pre-processing, device description table processing, adapter description table processing and post-processing. A list of the kernel requests is set forth in Table 7. Kernel requests are referenced numerically to support a common interface to loadable description tables. Thus, the kernel requests are referenced and called by number (i.e., each kernel request has a unique kernel request number assigned to it). The environmental map converts or maps an operating system request into one (or sometimes more than one) numerically referenced kernel request.

The operating system request and the kernel request each identify a block device unit number or a character device name which identifies the requested or targeted device and which is used by the sequencer to identify the device data structure of that device. The sequencer uses the entry in the CONTROL BYTE field of each pseudo device description table to determine if pre-processing is required. If pre-processing is required, the sequencer loops through each of the pre-processing pseudo device description tables by activating the cell processor for each in turn.

Data is stored in a data buffer before it is written to or read from a peripheral device. The pseudo device description table provides processing to translate this data before it is written to or read from a device. This processing is performed in a manner which is transparent to the operating system. The operating system is unaware of the existence of a pseudo device. For example, a pseudo device can encrypt and compress data before it is written to a peripheral device. A pseudo device performing this function is a pre-processing pseudo device. A pseudo device can be used to post-process data and decrypt or expand the data as it is read from a device. A pseudo device performing this function is a post-processing pseudo device. Also, a pseudo device can cache data before it is written or after it is read for a plurality of devices. In this case, the cache pseudo device can serve as both a pre- and a post-processing pseudo device.

Each pseudo device description table is activated in turn by the sequencer looping through the pseudo device description tables in an ordered sequence for those pseudo device description tables having their CONTROL BYTE set for pre-processing. This sequence is the ordered sequence in which the pseudo devices are found in the global data structure as shown in FIG. 3. Pre-processing for block devices is separate from, and precedes, pre-processing for character devices. As each pseudo device description table is activated, the pseudo device description table checks the DEVICE TYPE field associated with the character or block device which has been requested by the kernel request. If the contents of the DEVICE TYPE field match the device type value programmed into the pseudo device description table, the pseudo device description table proceeds to translate or process the data contained in the data buffer. If a match does not occur, the pseudo device creates an Exit State Machine control event and returns control back to the sequencer. The sequencer continues the loop through each of the pre-processing pseudo device description tables.

The above-described procedure is repeated in a similar manner for post-processing pseudo device description tables after data has been read from or written to a device (or devices), e.g., after logical and real device description tables and adapter description tables have been activated.

Activation of pseudo device description tables occurs as follows:

1. Pre-processing for block devices

2. Pre-processing for character devices

3. Post-processing for block devices

4. Post-processing for character devices

The cell processor is shown in FIG. 7 and is part of the code segment of the description table shown in FIG. 10. A cell processor is activated by the sequencer, i.e. the sequencer calls the description table's cell processor for execution. When the cell processor is to be executed, the CELL PROCESSOR ADDRESS field of the adapter or device data structure associated with the description table is accessed by the sequencer to determine the address to the cell processor in the description table. The cell processor is called by the sequencer and gains control to continue processing of the kernel request. The cell processor obtains from the STATE EVENT TABLE ADDRESS field of the device or adapter data structure the address (which may be in the form of an offset) of the state event table of the description table. The cell processor accesses the state event table to determine which action routine is to be activated from the action list.

The state event table is shown in FIG. 7. The state event table consists of rows and columns of cells. Each cell contains two entries, the desired action to be selected from the action list and the next state. Each row of the state event table is assigned a state number. Each column is assigned an event number. Event numbers correspond to kernel request numbers, thus there is a column for each kernel request.

When accessing a device or adapter description table for the first time, the sequencer sets up an INIT (initial) state (i.e. zero) in the CURRENT STATE field of the device or adapter data structure. In addition, the sequencer sets up pointers to the device or adapter data structure and passes these pointers to the cell processor when the cell processor is called. These pointers give to the independently written description tables the addresses of all data contained in the data structure which are necessary for the description table to interface with the kernel and to function. The sequencer coordinates this data with other description tables. Direct linkage between description tables does not exist because each description table is an independent module. Description tables are linked to each other through the kernel.

The cell processor, using the contents of the CURRENT STATE and LAST EVENT fields of data structure associated with the description table, accesses the state event table cell which is the intersection of the state row and event column in the state event table. This cell contains an action reference to a routine in the action list. This action reference is an index to an entry in the action pointer array. The action pointer array points to an action routine in the action list. The action routine is executed by the digital computer to cause an action routine function. For a device description table, the desired action routine function can be the creation of an adapter request, a call to another device description table, a call to itself (i.e. the same device description table), a transformation of the kernel request, etc. For an adapter description table, the desired action routine function can set up adapter registers, can cause data to be transferred by the adapter from the data buffer to the referenced device, etc.

FIG. 7 illustrates an example. When the sequencer first activates a description table, the sequencer initializes the CURRENT STATE field to an initial state equal to 0. For the example in FIG. 7 the kernel request number is 2. Therefore, the sequencer sets state 0 into the CURRENT STATE field and a 2 in the LAST EVENT field of the data structure. The cell processor is called by the sequencer. The cell processor uses the contents of the CURRENT STATE and LAST EVENT fields to index into the state event table. It finds that the cell (at row 0, column 2) contains an action reference to Action B. The cell processor uses the Action B reference as an index into the action pointer array. Using the address in the B entry of the action pointer array, the cell processor calls Action B. Action B is then activated (i.e. executed) and performs its function. An example of a typical action routine is a routine that creates an adapter request having a device command (e.g. CDB) and an adapter description table command. Another example is a routine that sets up registers on an adapter. When an action is completed, the LAST EVENT field normally remains unchanged but in some cases may be changed. For example, when Action B is completed, the LAST EVENT field remains equal to 2. Control is passed from the action routine back to the cell processor which returns control back to the sequencer. The sequencer interrogates the LAST EVENT field of the data structure. Since the LAST EVENT field contains a 2, the sequencer interrogates the state event table cell which is at the intersection of the CURRENT STATE (row) and the LAST EVENT (column) (i.e., the cell at row 0 and column 2). The sequencer extracts the Next State from this state event table cell and places it in the CURRENT STATE field of the data structure. With the CURRENT STATE and LAST EVENT fields set up in the data structure, the sequencer then calls the cell processor. The cell processor repeats the action of selecting an action reference from the state event table cell and continues the process. This process of coordination between the sequencer and the cell processor continues until the action routine called creates a control event by placing the control event number into the LAST EVENT field. Table 9 of Section VIII is a list of control events and their assigned numbers. Control events are caused by action routines and are action routine functions. Control events can instruct the sequencer to exit the description table because it has completed processing, or invoke additional description tables for the processing of default device description tables or an adapter description table.

The state machine sequence described above is applicable to the description tables in this embodiment of the invention. Description tables can be invoked by the sequencer using linkages supplied by the memory management and table operation sections of the device or adapter data structure which is contained in the global data structure. Tradeoffs can be m