OS/2 Device Drivers Information

From EDM2
Revision as of 00:48, 20 March 2018 by Ak120 (Talk | contribs)

Jump to: navigation, search

Description of OS/2 Warp Version

The term OS/2 Warp will be used as a generic term for the following OS/2 Versions:

  • OS/2
  • OS/2 Warp Version 3
  • OS/2 Warp Connect
  • OS/2 Warp with WIN-OS/2

OS/2 Security System

OS/2 switches the Intel 80286. 80386, 80486 and 80586 Microprocessor chips into Protected mode operation. In this mode of operation, OS/2 Warp can run applications in one of four ring modes: RING 0, RING 1, RING 2, and RING 3.

Ring 3 
is reserved for normal applications. From Ring 3 the Operating System cannot be accessed directly.
Ring 2 
is reserved for I/O program (IOPL-Input/Output Privilege Level)
And some 16-bit dynamic link libraries (32-bit DLLs run at Ring 3).
Ring 1 
is reserved by the kernel and is not used.
Ring 0 
is the most protected area. It is used from the operating system Kernel.
Device drivers run in this ring.

CONFIG.SYS Processing Sequence

  • When you turn on a Personal Computer it immediately performs the Power On Self Test (POST) to ensure the hardware is working correctly. A single beep indicates there are no hardware errors and the operating system can be loaded.
  • Once the OS/2 kernel is loaded successfully the CONFIG.SYS file is read and executed. Unlike the DOS environment,
  • Where the CONFIG.SYS file was read and processed line-by-line, OS/2 reads the entire CONFIG.SYS file and then organizes all statements into ordered groups for execution.
  • Early in the boot sequence of OS/2 the OS2KRNL file is loaded and executed. After the kernel is running, OS/2 searches the root directory of the drive OS/2 is installed on for the CONFIG.SYS file.
  • Once CONFIG.SYS is successfully read, OS/2 reorganizes and reorders each line into a new sequence for processing. If CONFIG.SYS in the root directory is damaged or missing, you receive the error message and the boot process halts:

Config.sys Group Execution order

  1. First, all base device driver statements are executed according to their file name extensions.
  2. Then the LIBPATH statement and all environment variables are created in memory.
  3. National language support is next which involves the CODEPAGE, COUNTRY, and DEVINFO statements.
  4. Files systems are loaded next
  5. Installable device drivers from all DEVICE commands
  6. The SWAPPATH is established next and the swap file is opened on physical storage.
  7. OS/2 then initializes the Virtual DOS Machine environment for DOS and Windows programs.
  8. CALL and RUN commands are interrogated next prior to executing the Workplace Shell.

Config.sys Group Execution order Commands

  1. BASEDEV=
  2. LIBPATH=/SET=
  3. CODEPAGE=/COUNTRY=/DEVINFO=
  4. IFS=/DEVICE=
  5. SWAPPATH=
  6. VDM Support:
    • BREAK=
    • DEVICE=
    • DEVICEHIGH=
    • FCBS=
    • FILES=
    • LASTDRIVE=
    • PROTECTONLY=
    • RMSIZE=
    • SHELL=
  7. CALL=/RUN=
  8. PROTSHELL=
  9. Others

The detailed processing sequence and the drivers within each of those Groups

BASEDEV=

statements are read first and ordered by the file extension as follows:

  1. .SYS
  2. .BID
  3. .VSD
  4. .TSD
  5. .ADD
  6. .I13
  7. .FLT
  8. .DMD

The extensions .BID, .VSD and .TSD are used to support Microsoft's LADDR layered device driver model, which is now rarely used in OS/2.

LIBPATH=/SET=

The LIBPATH= statement is read next. LIBPATH is not an environment variable like the PATH and DPATH statements. It cannot be displayed or modified from an OS/2 command prompt like PATH and DPATH can.

If changes are made to CONFIG.SYS, the system must be rebooted to read and load the new LIBPATH statement. When any application searches for dynamic link libraries, it looks in the LIBPATH directory structure first

If you add a "." to the beginning of the LIBPATH= statement you force OS/2 to search the current directory for DLLs first. The "." represents or points to the address of the current directory. Any time a system application or user program makes a call for a dynamic link library, during the boot sequence or normal operation, this causes the Current directory to be searched.

After all LIBPATH= statements are read OS/2 reads all the SET statements in the order that they appear and initializes environment variables for each SET command.

CODEPAGE=/COUNTRY=/DEVINFO=

The National Language Support for screen and keyboard are read next.

IFS=/DEVICE=

Installable File Systems (IFS) are read and loaded next including High Performance File System (HPFS), CD- ROM File System (CDFS), and High Performance Optical File System (HPOFS) if required and installed. Storage devices requiring any installable file system cannot be accessed. if the appropriate IFS support is not successfully loaded.

SWAPPATH=

The SWAPPATH statement points to the location of the SWAPPER.DAT file. It is only read at boot time and if changed, the system must be rebooted.

VDM Support:

If DOS support is installed, OS/2 initializes parameters that are specific to the Virtual DOS Machine from the CONFIG.SYS file. These statements cannot be removed from CONFIG.SYS but they can be set to minimal values. Refer to the Command Reference in the Information folder for specific details on minimum, maximum, and default values when appropriate. 

BREAK=
DEVICE=
DEVICEHIGH=
FCBS=
FILES=
LASTDRIVE=
PROTECTONLY=
RMSIZE=
SHELL=

CALL=

The CALL= statement is used to start a program before the Workplace Shell is initialized and loads the Desktop. Programs launched using the CALL= statements in CONFIG.SYS are run synchronously. This means:

That the first program called must complete before the next CALL= statement is executed. This method allows control to be exercised during the startup sequence prior to initializing the Workplace Shell.

For instance, if you want to be able to execute a command before the Workplace Shell is initialized, you could put the statement, CALL=C:\OS2\CMD.EXE in the CONFIG.SYS file.

When this CALL statement is executed an OS/2 Command Prompt window will be opened. You can now enter any command you wish. Click on EXIT to close the window and allow the boot process to continue.

After the Workplace Shell initializes and the Desktop is built, certain files are in a locked for protection from other processes. Any attempt to modify or reconfigure one of these files will fail. The CALL= statement allows access to these files before they are locked by OS/2.

RUN=

The RUN= statement is similar to the DETACH command in that it starts a detached process in OS/2. A detached process runs in the background with no access from standard input or to standard output (keyboard or Screen). All input must be piped in from another source and all output similarly must be piped or redirected to a file or storage device. There are two important aspects of the RUN= statement to be aware of:

  • The RUN= statement executes the program before the Workplace Shell is initialized.

All that is running at this time in the boot sequence is the base operating system. If your program requires the Workplace Shell or Presentation Manager. Services the program will fail to start or possibly cause other errors on the system.

  • Programs started with the RUN= statement in CONFIG.SYS are executed asynchronously. This means that each RUN= statement is started in the order that it appears in CONFIG.SYS and all programs started with a RUN= statement execute simultaneously. You can control the order of initial execution, but you cannot control which program will run faster or complete processing first. If control is important, use the CALL command.

PROTSHELL=

PROTSHELL= tells OS/2 what Presentation Manager program to use as the Protected Mode Shell. By default OS/2 installs and uses PMSHELL.EXE. PMSHELL.EXE is the first program started after the base operating system is loaded. This is the only Protected Mode Shell program provided with OS/2 Warp, though there might be others from Private sources.

The Protected Mode Shell program is responsible for initializing the Presentation Manager. Environment. This initialization process uses some undocumented features in OS/2 Warp, making it difficult to write a new Presentation Manager.

Other CONFIG.SYS Statements All other CONFIG.SYS statements that do not fit into one of the above groups are not sequence sensitive and are initialized sometime during the OS/2 boot process.

OS/2 Warp Device Driver Overview

Introduction

  1. Device drivers are software components to implement a device-independent way to access devices. This reduces the Development overhead for applications.
  2. To achieve this, a well-defined interface from the application's point of view needs to be available to use the device.
  3. All the device-dependent code resides in the device driver. Therefore it's necessary to have different drivers for different devices.
  4. Device drivers set up hardware and software components of the system.

The Three major categories of device drivers in OS/2 Warp are as follows:

I) Physical device drivers

II) Virtual device drivers

III) Presentation drivers

I) Physical Device Drivers

  • These drivers usually handles I/O requests, e.g. Disks, hard disks, CD-ROMs, Video, Mouse, Keyboard, serial/parallel ports etc. This workshop will cover parts of these types of drivers.
  • OS/2 physical device drivers are 16 bit protected mode applications running in ring 0. They need to be reentrant and fast, because OS/2 is a multitasking system.
  • Physical device drivers are loaded from CONFIG.SYS with the BASEDEV= or DEVICE= statement.
  • These drivers provide support for standard I/O Devices such as a hard disk drive, printer and a fax/modem card.
  • Device drivers are initialized at Ring 3 but operate at Ring 0, the most privileged level of the operating system.
  • Physical device drivers are loaded by two different methods. The OS/2 kernel loads some, and the others are loaded by entries in the CONFIG.SYS file.
  • Device drivers entered in the CONFIG.SYS file are loaded by either the BASEDEV= statement or the DEVICE= statement. For the purpose of this discussion

Physical device drivers will be organized into the following three categories (This is based on Data Accessing):

1) Block Device Driver

2) Character Device Driver

Block Device Driver

  • A block DD accesses data in block or record structure.
  • Usually these drivers can do random access, using DMA and the read operation is non-destructive.
  • OS/2 assigns drive letters for Block Devices. Each driver may handle more than one letter.

Character Device Driver

  • A character DD accesses data character oriented, often bytes or streams. Usually these drivers access data sequentially e.g. I/O for special hardware chips, like programmable I/O circuits.
  • OS/2 assigns names for these drivers e.g. MOUSE$ or LPT1. The driver may support more than one device with the same driver.
  • A character DD may be replaced by an other one with the same name (it depends on the loading sequence). This means, that such a driver needs to have a mechanism to unload. This workshop will cover parts of this PDD type.

Physical device drivers will be organized into the following three categories (This is based on the Functionality):

  1. Critical device drivers
  2. Base device drivers
  3. Installable device drivers

1) Critical device drivers

  • Critical device drivers are absolutely essential to the Operation of OS/2 Warp.
  • They are so important they are loaded by the OS/2 kernel (OS2KRNL) during system Initialization. If one of these device drivers isn't found and fails to load, OS/2 Warp will not load. For example, we renamed the RESOURCE.SYS file in the \OS2\BOOT subdirectory and rebooted the system. After the single beep of the Power On Self Test (POST), we received the following message and the system was halted The system is stopped. Correct the preceding error and rest system.
  • If you lose one of the following critical device drivers for Any reason, you will need to replace it from another Machine or unpack it from the install diskettes into the Proper subdirectory. The proper subdirectory for these device drivers is \OS2\BOOT.
  • These device drivers are installed during initial installation and should not be Manually modified in any way or deleted from the system. If you receive an Error on one of these device drivers, it could be a very serious problem requiring a reinstall of the operating system.
Device Driver Device Driver Description
  • RESOURCE.SYS OS/2 Resource Manager.
  • CLOCK01.SYS System clock device driver for ISA bus personal computers.
  • CLOCK02.SYS System clock device driver for MCA bus personal computers.
  • SCREEN01.SYS System standard output device driver for ISA bus computers.
  • SCREEN02.SYS System standard output device driver for Micro Channel bus computers.
  • KBDBASE.SYS This is the base OS/2 keyboard device driver. It receives and processes scan code from IBMKBD.SYS, the hardware specific device driver for the particular keyboard attached to the system unit. KBDBASE.SYS instructs IBMKBD.SYS if there are any updates to the keyboard information.

Base device drivers

  • Base device drivers are primary level support for system devices such as diskette drives, fixed and removable; storage devices, system attached printers, and some other Hardware devices.
  • These device drivers are loaded with a BASEDEV= statement in the CONFIG.SYS file. These system-level device drivers communicate with the device-level driver that communicates directly to the supported device. BASEDEV statements are interrogated and loaded prior to any other DEVICE statements. Unlike the DEVICE statement, the BASEDEV= statement cannot contain either drive or path information and therefore the OS/2 operating system cannot process such information at this stage of the startup sequence.
  • Support for file systems (File Allocation Table – FAT and High Performance File System - HPFS) is not initialized at this point in the boot process.
  • OS/2 first searches the root directory of the startup partition for the specified File name, then the \OS2\BOOT directory. If drive or path information is Included in a BASEDEV= statement.
  • The BASEDEV=statement including the path information is not read and CONFIG.SYS processing continues. If the BASEDEV= statement is as critical as the BASEDEV=IBMKBD.SYS (keyboard support) the system will eventually hang. If the base device driver is not critical the system will load successfully without device support provided by that particular BASEDEV=statement.
  • For example, if you include BASEDEV=C:\OS2\BOOT\IBM1FLPY.ADD in CONFIG.SYS, you will generate the above described message during the boot sequence. After a few seconds the message disappears and processing continues. The system will boot normally and the Workplace Shell will initialize. When you attempt to access the diskette drives in your computer, either from a command prompt or the Workplace Shell, you will receive one or both of the following error messages:
  • For OS/2 Symmetric Multiprocessing (SMP), the Platform Specific Driver (.PSD) provides the strategy and management code to exploit the multiple processors in SMP machines. There is one .PSD for each machine type, as the manufacturers tend to implement SMP in slightly different ways. As of this writing a platform specific driver for OS/2 Warp was not yet generally available.

The following is a list of all base device drivers included with OS/2 Warp:

  • IBMKBD.SYS Device support for the keyboard.
  • IBM1FLPY.ADD Device support for diskette drives on non-Micro Channel workstations.
  • IBM2FLPY.ADD Device support for diskette drives on Micro Channel workstations.
  • XDFLOPPY.FLT Device support for XDF diskettes.
  • OS2DASD.DMD General-purpose device support for hard disk drives.
  • IBMINT13.I13 General-purpose device support for hard disk controllers.
  • IBM1S506.ADD Device support for non-SCSI disk drives on non-Micro Channelworkstations.
  • IBM2ADSK.ADD Device support for non-SCSI disk drives on Micro Channel Workstations.
  • IBM2SCSI.ADD Device support for Micro Channel SCSI adapters.
  • DELIVERY.SYS IBM 32-bit Fast & Wide Microchannel adapters. (IBM2SCSI.ADD must be installed and initialized.)
  • OS2SCSI.DMD General-purpose device support for non-disk SCSI devices.
  • OS2ASPI.DMD Device manager for devices using Adaptec's AdvancedSCSI

Programming Interface (ASPI).

  • AHA152X.ADD Adaptec ISA SCSI adapters and system board controllers.
  • AHA154X.ADD Adaptec ISA SCSI adapters.
  • AHA164X.ADD Adaptec MCA SCSI adapters.
  • AHA174X.ADD Adaptec EISA SCSI adapters.
  • AIC7770.ADD Adaptec 2800 ISA and 2700 EISA SCSI adapters and AIC-7770 system board controller.
  • AIC7870.ADD Adaptec PCI SCSI adapter and 7870 system board controller.
  • FD8XX.ADD Future Domain 8-bit SCSI adapters.
  • FD16-700.ADD Future Domain 16-bit, PCI SCSI, and ISA Fast SCSI adapters.
  • FD7000EX.ADD Future Domain TMC-7000EX EISA SCSI controllers.
  • BTSCSI.ADD Bus Logic ISA-VL, ISA, MCA, EISA, and PCI SCSI adapter support.
  • DPT20XX.ADD Distributed Processing Technology (DPT) SCSI adapters.
  • PRINT01.SYS Device support for locally attached printers on non-Micro Channel workstations. Use the /IRQ parameter to use interrupt driven printing, rather than the default polling method. Polling can use a significant amount of a CPU doing nothing if the printer is slow.
  • PRINT02.SYS Device support for locally attached printers on Micro Channel workstations.
  • SBCD2.ADD IBM ISA CD-ROM, Creative Labs Omni CD-ROM, and Panasonic 521/2/3, and 562/3.
  • IBMIDECD.FLT IBM filter device driver for Enhanced IDE CD-ROM drives.
  • MITFX001.ADD Mitsumi CRMC-FX001/001D and LU0025/55 CD-ROM drives.
  • SONY31A.ADD Sony CDU-31A/33A and 7305 CD-ROM drives.
  • SONY535.ADD Sony CDU-531/6201/6205/535/6205 and 7205 CD-ROM drives.
  • LMS205.ADD Philips LMS CM205/225 CD-ROM drives.
  • LMS206.ADD Philips LMS CM205MS/255MS and CM206/226 CD-ROM drives.
  • PCMCIA.SYS Card services support for PCMCIA devices.
  • IBM2XXXX.SYS Socket services support for PCMCIA devices.
  • AUTODRV2.SYS PCMCIA modem driver.
  • PCM2ATA.ADD PCMCIA Advanced Technology Attach (ATA)/Flash support.
  • ICMEMMTD.SYS PCMCIA Flash RAM Drive support.
  • ICMEMCDD.SYS PCMCIA Static RAM Drive support.
  • CSSCSI.SYS IBM PCMCIA SCSI card support.
  • DETNE2.SYS Detects NE2000 Ethernet LAN cards and blocks address to prevent conflicts (for example, Mitsumi CD-ROM).

Installable device driver

  • Installable device drivers are program files required by OS/2 in order to recognize hardware devices and process information received from or sent to that device.
  • These Files use the extension .SYS and may have associated Dynamic Link Libraries (DLLs). Examples of device drivers with a corresponding DLL are ANSI.SYS and ANSI.DLL, which provide extended screen and keyboard support.

Some typical device drivers from the C:\OS2\ subdirectory are:

RESOURCE.SYS
Scans allocated resources in the system to determine conflicts with I/O port allocation, IRQ levels, BIOS memory allocation, DMA channels, Timer channels, and device drivers.
COM.SYS
Serial device support. Permits programs to use serial ports. The IRQ and I/O port address are configurable via this device driver.
RESERVE.SYS
Used to reserve specific system resources for device drivers that are not Resource Manager aware. Works in conjunction with RESOURCE.SYS.
PMDD.SYS
OS/2 Presentation Manager device driver. It is not required if you only run OS/2 full screen sessions. It also provides pointer draw support for OS/2 PM sessions.
VDISK.SYS
To create a virtual disk drive in RAM memory. The default size is 16 KB. Virtual disks provide extremely fast access to programs and data, but consume RAM memory that cannot be used by applications.
EXTDSKDD.SYS
Assigns a drive letter to a diskette drive.
LOG.SYS
Activates the Systen-Error Logging Service device driver. The /OFF parameter pauses the System-Error LoggingService at initialization. When paused, no error-logging occurs. LOG.SYS is used in conjunction with the RUN=LOGDAEM.EXE statement in CONFIG.SYS.
POINTDD.SYS
Provides mouse pointer draw support.
DOS.SYS
Support for Virtual DOS Machines (VDM's) in OS/2 Warp. If you don't run DOS applications you can remove this device driver.
MOUSE.SYS
Support for pointing devices.
TESTCFG.SYS
Tests the system configuration, for example, queries adapters, during initial installation and subsequent installs; that is, Selective Install or Device Driver Install. Can be removed if not performing install functions, but not recommended.
IBMKBD.SYS
Hardware specific portion of the keyboard device driver. It supports the following keyboards: IBM 101/102 Enhanced keyboards, IBM 3279 130 Enhanced keyboard.

II. Virtual Device Drivers

  • These drivers are ONLY necessary for the Virtual DOS Machine (VDM) and for DOS applications like WinOS/2 and others. Usually these drivers communicate with Physical Device Drivers to gain access to devices. Virtual Device Drivers are implemented in 32 bit code, running in ring 0.
  • Virtual Device Drivers (VDDs) are installed to allow DOS applications to access hardware devices in the OS/2 protected environment.
  • DOS programs cannot be allowed to monopolize hardware devices for their exclusive use, and OS/2 accomplishes this through a technique known as hardware virtualization.
  • It does so using virtual device drivers. VDDs are 32-bit programs that operate at Ring 0.
  • They communicate with the actual hardware through an OS/2 layer called the Virtual Device Helper (VDH). The VDH monitors the availability of the hardware device and allows the DOS application access when it is free.
  • All VDDs are loaded from the CONFIG.SYS file and begin with the letter V. They are located in the \OS2\MDOS\ subdirectory on the drive which OS/2 is installed

Device Driver Device Driver Description

  • VAPM.SYS This driver is used to support Advanced Power Management under DOS. If your system does not have APM, then you don't need this driver and it can be removed from CONFIG.SYS.
  • VCDROM.SYS This driver provides DOS CD-ROM support. If you do not use DOS programs that require CD-ROM support, you can remove this driver from CONFIG.SYS.
  • VCOM.SYS This driver provides DOS COM support. If you do not use DOS programs that require access to COM ports, you can remove this driver from CONFIG.SYS.
  • VDPMI.SYS This driver, along with VDPX.SYS, provides DOS Protected Mode Interface memory support. If you do not use DOS programs that require DPMI you can remove this driver from CONFIG.SYS. Note that this driver is required for Windows.
  • VDPX.SYS This driver, along with VDPMI.SYS, provides DOS Protected Mode Interface memory support. If you do not use DOS programs that require DPMI, you can remove this driver from CONFIG.SYS. Note that this driver is required for Windows.
  • VEMM.SYS This driver provides support for the DOS virtual expanded memory manager. If you do not use DOS programs that require expended memory you can remove this driver from CONFIG.SYS.
  • VMOUSE.SYS This driver provides mouse support in the DOS and WIN-OS/2 environment. If you do not use DOS or WIN-OS/2 programs that require mouse support, you can remove this driver from CONFIG.SYS.
  • VSVGA.SYS This driver provides DOS SVGA support. If you do not use DOS or WIN-OS/2 programs, you can remove this driver from CONFIG.SYS.
  • VPCMCIA.SYS This driver provides DOS PCMCIA support. If you do not use DOS programs that require PCMCIA, you can remove this driver from CONFIG.SYS.
  • VVGA.SYS This driver provides DOS VGA support. If you do not use DOS or WIN-OS/2 programs you can remove this driver from CONFIG.SYS.
  • VWIN.SYS This driver provides WIN-OS/2 support. If you do not use WIN-OS/2 programs you can remove this driver from CONFIG.SYS. The VWIN.SYS driver also requires the VDPX.SYS, VDPMI.SYS, and VXMS.SYS to be loaded.
  • VW32S.SYS This driver provides support for the Win32s APIs under WIN-OS/2. If you do not use WIN-OS/2, or Windows programs that use Win32s, then you can remove this Driver from CONFIG.SYS.
  • VXGA.SYS This driver provides DOS XGA support. If you do not use DOS or WIN-OS/2 programs, you can remove this driver from CONFIG.SYS.
  • VXMS.SYS /UMB This driver provides support for the DOS virtual extended memory manager. If you do not use DOS programs that require extended memory, you can remove this driver from CONFIG.SYS.

III) Presentation Drivers

  • The I/O interface of the Presentation Manager (PM) uses these driver types so only PM-Applications use these drivers (indirectly). These drivers handle the PM device contexts to draw to a virtual device (e.g. printer and screen). Presentation Drivers are implemented with 32 bit code running in ring 3 and some parts with 16 bit, running in ring 2 to gain I/O access.
  • The Presentation Manager I/O interface for output devices is a high-level interface. This interface is similar to the API call interface, which uses the program stack to communicate with, or pass parameters to, the presentation drivers.
  • These drivers are special-purpose I/O routines operating with I/O privileges at Ring 2 or Ring 3.
  • Their main function is to process function calls made by the Presentation Manager interface on behalf of Presentation Manager applications. Hardcopy presentation drivers, or drivers that directly support file printing, communicate with OS/2 device drivers through the file system emulation functions. Display presentation drivers interface directly with the hardware.
  • Presentation drivers are dynamic link library modules that are supplied as files and identified by the extension DRV. When the Presentation Manager interface is initialized, the display presentation driver is loaded and enabled automatically. Other presentation drivers (for example, the hardcopy presentation drivers) are loaded and enabled when an application calls the DevOpenDC function to open the device.
  • Presentation drivers service requests only from applications running in Presentation Manager sessions in OS/2 mode. Output data and requests for information are passed to the presentation driver as function calls to the presentation driver interface.
  • The definition of the call interface is given in terms of the codes, and data is passed to the presentation driver interface through the program stack.
  • Header and include files are shipped with the OS/2 operating system to provide support for building presentation drivers that are written in C or assembler language. These files contain function prototypes, defined values, and data structures used by the various functions.

Application to driver communication

Applications can only communicate with drivers by using the following kernel API functions:

  1. DosOpen()
  2. DosClose()
  3. DosRead()
  4. DosWrite()
  5. DosDevIOCtl()

The advantage in using the standard file API functions also for character DD's is, that redirection is possible for these devices too. The character DD's name is used as the filename for these functions.

Now we can discuss about Physical Device Driver

PDD execution context

Each driver operates in three different contexts.

1)INIT Mode

2)Kernel Mode (context mode)

3)Interrupt Mode (and timer mode)

INIT Mode:

This mode is exclusively used at OS/2 boot time (driver load). The code in this mode runs at ring 3 privilege level. In this mode, the driver has access to some "standard" OS/2 API's and has I/O privilege! This mode is only used once and therefore the code in this mode only runs at boot time. The driver developer should not spend too much time to make this code fast...

Kernel Mode (context mode)

If one of the above 5 API functions are used, the kernel calls the driver and routes the function request with the parameters to the driver. This is the typical operation of the driver. The driver will run in the context of the application which made the function call. The code, which implements this mode, is called the strategy routine. This code should be fast... - spend more time

Interrupt Mode (and timer mode):

In this mode, the driver is called via an interrupt. The driver will NOT run in a specific context! This code should be fast, and very fast if it is a timer interrupt.

The Drivers Layout

  • PDD are written in 16:16, protected mode addressing schema. The first segment needs to be the data segment. OS/2 expects a data structure at the very first position of a driver, called the "Device Driver Header". Because this is data, the first segment needs to be the data segment. Data, which is accessed by the interrupt handler, must reside in this segment.
  • The code segment follows directly after the data segment. Code for the interrupt handler must reside here.
  • The code for the INIT-mode could be placed at the end of the code segment. So it could be freed after running, because it only runs once.

PDD header

The PDD header defines the characteristics of a driver.

SNO Field Description Length in Bytes
A far pointer to next device header 4
B Device attribute 2
C 16 bit offset to strategy routine 2
D 16 bit offset to inter-device-driver-communication(IDC) routine 2
E Driver name (character DD) / number of units (blockDD) 8
F Reserved 8
G Capabilities bit strip 8

A) far pointer to next device header

This pointer should be set to ­1 (ffffffff) in the driver's code. While loading the drivers, OS/2 builds a linked list for all drivers by using this field. If the driver supports multiple devices, there is one header for each device. Only the last header should be set to ­1 the other ones need to be linked together.

B) device attribute

Describes the characteristics of the physical device driver to the system.

CHR (bit 15)
Set, if the physical device driver operates in character mode. Bit 15 is the device type bit. Use bit 15 to tell the system if the device driver is a block or character device. For block device drivers, bit 15 is 0. For character device drivers, bit 15 is 1.
IDC (bit 14)
Set, if the physical device driver participates in inter-device-driver communication (IDC). Bit 14 is the IDC bit and indicates that the offset to the IDC entry

point in the physical device driver header is set.

IBM (R) (bit 13)
Set, if non-IBM block format (block device drivers only). For block device drivers, bit 13 indicates the method which the physical device driver uses to determine

the media type. If a block device driver uses information in the BIOS Parameter Block (BPB) to determine the media type, bit 13 should be set to 1. If the physical device driver uses the media descriptor byte to determine the media type, bit 13 must be 0.

SHR (bit 12)
Set, if the device driver supports shared-device access-checking (character

devices). Bit 12 is the shared bit. It is set if the device name is not to be protected by the sharer. Bit 12 has no meaning for block device drivers and must be 0. If clear (default), file system sharing rules do not apply to the device, and the physical device driver provides contention control. If set, file system sharing rules apply to the device, just as these rules apply to any other file system name. In addition, any given physical device can have only one logical name. (Devices cannot have aliases.)

OPN (bit 11)
Set, if the device driver supports removable media (block devices) or device

open/close (character devices). For block device drivers, bit 11 is the removable media bit. If set, this bit indicates that the physical device driver handles removable media. For character device drivers, bit 11 is the open/close bit. If set, this bit indicates that the physical device driver must receive OPEN and CLOSE request packets.

bit 10
Reserved=0.
bits 9-7
bits 9-7 indicate the physical device driver function level, where:
Bit 9 Bit 8 Bit 7 Description
0 0 1 OS/2 driver (default) [Level 1 driver]
0 1 0 Supports DosDevIOCtl2 and shutdown requests [Level 2 driver]
0 1 1 Uses a capabilities strip bit in the header [Level 3 driver]
bit 6-4
Reserved=0.
CLK (bit 3)
Set, if CLOCK device. Bit 3 is the clock device bit. It is used by a character

device driver to indicate the system clock device.

NUL (bit 2)
Set, if NULL device. Bit 2 is the NULL attribute bit. It is used by character

devices only. Bit 2 is used to tell the OS/2 operating system if the character device driver is a NULL device. Although there is a NULL device attribute bit, the NULL device cannot be reassigned.

SCR (bit 1)
Set, if standard output device (STDOUT). For character devices, bits 1 and 0

are the standard input or standard output bits. These bits are used to tell the OS/2 operating system if the character device driver is the new standard input or standard output device.

KBD (bit 0)
Set, if standard input device (STDIN). See above.

C) 16 bit offset to strategy routine

This is the entry point to the code running in kernel mode. The kernel is using this address to call the strategy routine.

D) 16 bit offset to inter-device-driver-communication (IDC) routine

This address could be called by other device drivers to provide IDC.

E) driver name (character DD) / number of units (block DD)

For character DD's, the name needs to be in uppercase, left oriented and filled up with blanks until the length is 8 bytes. The device name takes precedence over file names! To avoid conflicts, sometimes a driver's name uses special symbols, like a $ sign. Block DD's fill in the number of supported units.

F) reserved

reserved area for future use

G) capabilities bit strip

Level 3 device drivers have an additional 8 byte field appended to the device header. Each bit of this new field is a flag indicating whether or not a particular feature is supported.

bit 0

Set to 1, if DosDevIOCtl2 request packets are supported, and if shutdown support is provided.

bit 1

For block device drivers, this bit is reserved and must be set to 0. Block device drivers indicate their ability to support higher than 16 MB. For character device drivers, this bit is set to 1 (if memory addressing above 16 MB is supported).

bit 2

Set to 1, if the physical device driver supports parallel ports.

bit 3

Indicates that the physical device driver is participating in the adapter device driver (ADD) strategy, which selects an alternate INIT request packet format from the kernel.

bit 4

If set to 1, the Initialization Complete Command (1Fh) is supported.

bits 5-31

Reserved. Must be set to 0.

How PDD's work

Strategy routine:

  1. If an application wants to communicate with the PDD, it calls one of the above kernel functions (e.g. DosOpen(), DosWrite(), ...).
  2. The kernel does some parameter checking and builds a data structure called request packet.
  3. The kernel calls the strategy entry point in the device driver and passes a pointer to the request packet. Pointers in the request packet (only for read/write requests) are already translated into a 32 bit physical address (already locked and verified), which is done automatically by the kernel. The strategy routine may build a request queue for further requests. Addresses received by IOCTL calls, are virtual addresses, not locked and not verified
  4. If the request can be answered in a short time, the strategy routine sets the return status in the request packet and ends. If the request can't be answered quickly (maybe the hardware isn't ready until yet), the driver should call a function to block the application thread. If the interrupt routine recognizes that the device is ready, the thread can be resumed. This mechanism is necessary to guarantee the multitasking mechanism. Code in the DD never preempts by the scheduler! You need to block the applications thread every time, if you can't directly deliver the result to the application. If the request can be answered directly, but it takes a lot of other calculation time In the strategy routine, yield the CPU every 3 milliseconds with a special function call.
  5. NO "standard" OS/2 API function call can be made in this mode! Only special device-helper-functions can be used!

Interrupt routine:

  1. The interrupt routine can be preempted by higher priority interrupts.
  2. If time critical device checking is performed, it's a good idea to disable interrupts (for a very short time), to avoid preemption.
  3. If the application thread has been blocked in the strategy routine, it can be resumed from the interrupt routine (if the data is available).
  4. NO "standard" OS/2 API function call can be done in this mode! Only special device-helper-functions can be used!

INIT routine:

  1. After the device driver is loaded (via a DEVICE= or BASEDEV= statement in CONFIG.SYS), this routine is called via the strategy routine. The request packet is marked as an INIT command.
  2. Command line parameters can be read.
  3. Because the context of this routine is a kernel thread, running at ring 3 with I/O privilege, some device initialization can be done here.
  4. Some "standard" API functions can be used in this mode:
DosBeep 
(Generate sound from the speaker)
DosCaseMap 
(Perform case mapping)
DosChgFilePtr 
(Change (move) file read/write pointer)
DosClose 
(Close file handle)
DosDelete 
(Delete file)
DosDevConfig 
(Get device configuration)
DosDevIOCtl 
(I/O control for devices)
DosFindClose 
(Close find handle)
DosFindFirst 
(Find first matching file)
DosFindNext 
(Find next matching file)
DosGetEnv 
(Get address of process environment string)
DosGetInfoSeg 
(Get address of system variables segment)
DosGetMessage 
(Get system message with variable text)
DosOpen 
(Open file)
DosPutMessage 
(Output message text to indicated handle)
DosQCurDir 
(Query current directory)
DosQCurDisk 
(Query current disk)
DosQFileInfo 
(Query file information)
DosQFileMode 
(Query file mode)
DosRead 
(Read from file)
DosSMRegisterDD 
(Register session switch notification)
DosWrite 
(Synchronous write to file)

Device Helper Functions

  1. Only these functions can be called for kernel services in the kernel and interrupt mode. Some of them could be called at INIT mode. The interface is called DevHlp interface, which provides these functions.
  2. One very important parameter is received with the first request packet while the driver gets initialized. This is a far pointer to the DevHlp entry point which needs to be saved by the driver to call the DevHlp functions, whenever needed!
  3. You need to look at the PDD reference guide to find out, which function can be called with which context. Not all functions are available at kernel (task time), interrupt and INIT context.
  4. There are about 90 DevHlp functions documented so far.

The functions can be grouped together into the following categories:

  1. Advanced BIOS Calls (ABIOS)
  2. Character Queue Management
  3. PDD-VDD Communication Services
  4. Context Hook Services
  5. Interrupt Management
  6. Memory Management
  7. Monitor Management
  8. Process Management
  9. Request Queue Management
  10. Semaphore Management
  11. System Clock Management
  12. System Services
  13. Timer Services

The Request Packet

The Request Packet, which is received by the driver’s strategy routine, is divided into two different parts. The "Request Packet Header" and the "Command Specific Data". The following request packet commands have been documented so far:

Code Function Block DD Character DD
0 INIT X X
1 MEDIA CHECK X
2 BUILD BPB X
4 READ X X
5 NONDESTRUCTIVE READ NO WAIT X X
6 INPUT STATUS X
7 INPUT FLUSH X
8 WRITE X X
9 WRITE WITH VERIFY X X
A OUTPUT STATUS X
B OUTPUT FLUSH X
D OPEN DEVICE X X
E CLOSE DEVICE X X
F REMOVABLE MEDIA X
10 GENERIC IOCtl X X
11 RESET MEDIA X
12 GET LOGICAL DRIVE MAP X
13 SET LOGICAL DRIVE MAP X
14 DEINSTALL X
16 PARTITIONABLE HARD DISKS X
17 GET HARD DISK/LOGICAL UNIT MAP X
1C SHUTDOWN X X
1D GET DRIVER CAPABILITIES X
1F INITIALIZATION COMPLETE X
Retrieved from "http://www.edm2.com/index.php?title=OS/2_Device_Drivers_Information&oldid=56183"