Browse Prior Art Database

Method for Implementing 32-bit Memory Access in a 16-bit OS/2 Device Driver

IP.com Disclosure Number: IPCOM000123229D
Original Publication Date: 1998-Jul-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 2 page(s) / 105K

Publishing Venue

IBM

Related People

Lehnertz, GK: AUTHOR

Abstract

Disclosed is a method for implementing 32-bit memory accesses from within a 16-bit OS/2 device driver. This method uses custom designed software routines in order to provide the appearance of a flat-memory (0:32) interface to a device driver that is architected to use segment:offset (16:16) memory access.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Method for Implementing 32-bit Memory Access in a 16-bit OS/2 Device
Driver

   Disclosed is a method for implementing 32-bit memory
accesses from within a 16-bit OS/2 device driver.  This method uses
custom designed software routines in order to provide the appearance
of a flat-memory (0:32) interface to a device driver that is
architected to use segment:offset (16:16) memory access.

   Conventional OS/2 (v2 or greater) device driver architecture
provides backwards compatibility for version 1.x drivers through the
use of a 16-bit system access method.  This limits the driver code to
using 64 Kb (16-bit) segments and 16-bit offsets within those
segments (16:16 memory access).  There is a significant overhead
involved in defining and accessing different segments of memory.  In
addition, translating between 16-bit operations at the driver level
and 32-bit operations within the operating system (thunking) involves
a great deal of cpu resources.  Through the use of 32-bit operations,
the overhead of switching segments and thunking is eliminated,
resulting in greatly increased speed and efficiency.

   The presently disclosed method incorporates modifications
to the driver initialization and run-time code with specialized
sub-routines to support the 32-bit interface.  The greatest amount
of processing is done during the driver initialization.  This
accomplishes two goals.  It is done only once at system startup,
minimizing any impact to the user; and it allows the actual data
transfers to execute far more rapidly since there is almost no
ancillary processing required prior to the memory accesses.

   At driver initialization time, the memory region that will
be the primary target or source is identified.  In most cases, this
is memory on an adaptor card within the system.  The memory address
and size are determined.  These are then used to obtain a mapping to
a Linear Address (LA) for that memory region.  If multiple regions
(adaptors) require support, a unique LA must be obtained for each.
These are stored as globally accessible values to be used for
run-time data transfers.

   In order to map a given system physical address to a
Linear Address, the initialization routine calls the VirtToLin()
DeviceHelp routine with the memory address to be mapped.  This call
converts a selector:offset pair into a linear address.  The mapping
process is completed by invoking the DeviceHelp function VMAlloc().
VMAlloc is passed the linear address, the memory space size, and a
flag indicating that a linear address mapping is to be returned from
the (linear) memory address and size parameters.  The...