Writing Device Drivers - Multiple Segments

by Steve Mastrianni

Occasionally I need to write a driver that occupies multiple code or multiple data segments. If you follow the guidelines presented here, you can avoid hours of frustrating development time.

The most fundamental change you will make is to use all far pointers and functions. This allows you reference functions and data across the 64KB segment boundaries, and requires the use of far calls to the DevHlp libraries. You can do this by modifying the DHCalls library on The Developer Connection Device Driver Kit for OS/2 or, if you are using the DevHlp library from Personal Systems Software, you can call (203) 693-0404 for an upgrade. Once you've converted the DevHlp library calls to FAR procedures, you must be sure to remove any NEAR references in your assembly language and C code. You'll need to change your compiler switches to use FAR calls as follows: cl -c -Alfu -Gs /NT_TEXT -G2 -Zl -Zp yourfile.c The /NT_TEXT parameter names the segment and allows you to order the segments at link time. As your first code segment approaches the 64KB boundary, you can name new code segments to a different name (for example, /NT_TEXT2), which will let you place the code in a second segment using the assembly language startup code and .DEF file. Of course, you must link with OS2286.LIB and the large model library, LLIBCEP.LIB, instead of SLIPCEP.LIB. ''Sample Code 1. Startup code''

Next, you must initialize all of your global variables. If you don't, the linker will attempt to place them in a second data segment ahead of your first code segment. Initializing your variables forces them into the default data segment. Once you've made the changes, compile and link your device driver and examine the map file to be sure all of your variables are initialized and reside in the default data segment. ''Sample Code 2. .DEF file for extra code segment''

You will have to change your .DEF file to order the segments correctly, and to mark the extra segments as IOPL. This will keep them around long enough to lock them down, which is your final step. In your driver's Init section, get the selector of any function which will reside in the upper segment, and call DevHlp Lock with that selector. Be sure to use the long-term lock. ''Sample Code 3. Locking the extra code segment''

Your device header requires offsets to the strategy and IDC routines, so declare them as NEAR before the header, or use another method of your choice.

Need more data space for those large buffers? No problem. Use the /ND option on the compiler command line to rename the data segments (for example, DATA2). Pick the name of a variable in the high data segment, get a pointer to it, extract the selector, and call LockSeg with the selector. cl -c -Alfu -Gs /NT_TEXT /ND_DATA2 -G2 -Zl -Zp yourfile.c

''Sample Code 4. .DEF file for extra data segment''

That's all there is to it. Well, almost - remember to mark your new data segment as IOPL.

Just because you've got all this new space, remember to use it sparingly!


 * Note:I write most of my device drivers in the small model, using Microsoft C 6.0.