1.3 Physical Device Driver overview
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!
1.3.1 OS/2 supports two types of PDDs
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.
1.3.2 Application to driver communication
Applications can only communicate with drivers by using the following kernel API functions:
DosOpen()
DosClose()
DosRead()
DosWrite()
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.
Each driver operates in three different contexts.
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.
Remember - PDD's 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!
Warpstock Europe 1999 |