Jump to content

SMPV211 - Device Drivers In OS/2 for SMP V2.11

From EDM2
Revision as of 18:58, 24 May 2025 by Martini (talk | contribs) (Created page with "{{SMPV211}} This chapter describes the impacts to driver writers when writing device drivers for OS/2 for SMP V2.11. Existing device drivers should run on OS/2 for SMP V2.11 without modifications providing two simple rules are followed: *The driver must call DevHlp EOI to perform an EOI. *The driver must not mask or unmask interrupts directly. OS/2 2.x device drivers were written with only 8259 architecture in mind. The code that is most commonly executed in a device...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation

OS/2 for SMP V2.11 Reference
  1. Notices
  2. Overview of OS/2 for SMP Version 2.11
  3. Platform Specific Drivers (PSDs)
  4. Understanding Spinlocks
  5. Device Drivers In OS/2 for SMP V2.11
  6. Application Considerations
  7. Avoiding Device Driver Deadlocks
  8. New Device Helper (DevHlp) Routines
  9. New Kernel Debugger Commands
  10. The Single Processor Utility Program
  11. OS/2 for SMP V2.11 Tools
  12. Appendix A
  13. Glossary

This chapter describes the impacts to driver writers when writing device drivers for OS/2 for SMP V2.11.

Existing device drivers should run on OS/2 for SMP V2.11 without modifications providing two simple rules are followed:

  • The driver must call DevHlp EOI to perform an EOI.
  • The driver must not mask or unmask interrupts directly.

OS/2 2.x device drivers were written with only 8259 architecture in mind. The code that is most commonly executed in a device driver is to send the End Of Interrupt (EOI) command to the 8259. There is a system interface for do this, however, for performance reasons some device drivers have decided to implement this function directly. Additionally, some device drivers may MASK or UNMASK interrupts or read the 8259 registers to determine the interrupt state.

Device Driver Spinlocks

The device driver should protect access to critical resources using spinlocks. The device driver allocates spinlocks in the Init routine by calling DevHlp_CreateSpinLock. CreateSpinLock returns a handle for use by the device driver. This handle is passed to DevHlp_AcquireSpinLock and DevHlp_ReleaseSpinLock. The spinlock is freed by calling DevHlp_FreeSpinLock. The driver may request any number of spinlocks, as the spinlocks are represented by a very small data structure. Once created, the spinlocks never go away.

As was outlined previously, OS/2 for SMP V2.11 contains a layer of abstraction for any functions that are deemed platform specific. These functions are placed inside the Platform Specific Driver (PSD) and isolate device drivers from the particular hardware platform that they are running on. At boot time, OS/2 determines and loads the appropriate PSD for the MP system hardware it is currently running on.

All device drivers that are MP-safe must use the appropriate kernel services to do hardware specific functions. The kernel will route these requests to the PSD for processing.

Device drivers in OS/2 2.x were written with the concept that only one processor can generate interrupts. But with OS/2 for SMP V2.11 other processors can now generate interrupts, so device drivers should account for re-entrance and parallel execution of task-time and interrupt-time code.