A flat model device driver for OS/2:Chapter 5. - Summary and Conclusions

Chapter 5. - Summary and Conclusions

Conclusions

It is worth reiterating here that the purpose of this effort was to flatten the existing base device driver model for OS/2. It would have been much easier to start from scratch with a brand-new architecture and to ignore the support for the 16-bit model, but this was not an option.

Since the drivers we used were written in C, the conversion process was much easier than we expected. All three drivers were converted with no major problems. The C header file conversion was also easy. The first step was to get the drivers to compile and link successfully using a 32-bit compiler. For the compiler, we selected IBM’s Visual Age C++ compiler for OS/2. Using a compiler that is supplied by IBM makes the most sense, since IBM also supplies the OS/2 operating system. We did not convert or use any assembly language stubs or programs because we did not want to supply a model that used them. Today’s C and C++ compilers do a great job at optimization, and any small performance gains realized by writing in assembler are insignificant compared to the software maintenance and support costs associated with assembler programming.

Recommended Steps

During the conversion process, we identified several steps that were necessary for the conversion of existing device drivers, and have arranged those steps above in Chapter 4, in their suggested order of implementation. This list is not complete because it only reflects the structure and coding techniques of the drivers we converted. Other drivers may use different coding techniques, library calls, or private data types, so the list should be used only as a general guideline when converting existing drivers.

Size

We were concerned that converting the drivers from 16-bit to 32-bit would cause an increase in size. Indeed, as we expected, the executable size of the drivers increased by an average of 30% or more, in one case the size increased 40%. However, given the choice of having no drivers or drivers that are larger, the choice is obvious.

Necessary Changes to OS/2

During the conversion process, we identified several major changes that must be implemented in the OS/2 kernel and file system to allow our new drivers to operate.

• All devices are accessed via the OS/2 file system. The file system is the operating system’s interface to all devices and I/O. The current file system implementation is 16-bit. The file system must be modified to support 32-bit device drivers and their associated data. This means that the file system must support 32-bit pointers. The challenge here is that the file system should continue to support existing devices and device drivers while adding support for 32-bit drivers and devices. Request packets that are sent to a 16-bit device driver should have the appropriate 16-bit pointers, while request packets that are sent to 32-bit drivers should use 32-bit pointers. We recommend that the number of request packets allocated by the system be doubled to 512 16-bit packets and 512 32-bit packets. Since the system supplies the driver’s stack, the stack pointers should be adjusted according to the driver model. Any system functions that are available to the device driver should have 16-bit and 32-bit entry points, allowing both models to coexist. For example, a call to set the entry point of the driver’s interrupt or timer handler should accept a segment:offset for a 16-bit driver and a 0:32 flat address for a 32-bit device driver. The driver must maintain the ability to handle pointer conversions on behalf of 16-bit applications. It may be, in fact, easier to flatten the file system completely and then add back in the support for 16-bit applications and device drivers. This would have the theoretical effect of enhancing OS/2’s support for large files and disk volumes, as well as faster file caching and buffering. The new file system must support long file names and large files (OS/2 currently supports files no larger than 2 GB).
• The OS/2 device driver loader must be modified to allow 16-bit and 32-bit device drivers to be loaded. 32-bit drivers can be loaded anywhere in memory, while 16-bit drivers will continue to be loaded in low memory (We assume low memory to mean the area of physical memory below the 1 MB boundary). The loader should not use the CONFIG.SYS file for loading device drivers, but should use the current configuration file to build a device tree while the system is booting up. The loader should support Dynamic Binding to allow the driver to be bound to an instance of the driver support library at load time.
• OS/2 must be modified to support file ring 0 file I/O services. This functionality is also required for the configuration manager to store the system configuration information.
• OS/2 must be modified to use the lower bits of the 8254 Counter-Timer to provide better granularity for system timer ticks and device driver profiling.
• OS/2 must supply a standard set of driver library functions that operate at ring 0 as well as ring 3. These libraries should export both 16-bit and 32-bit functions, and should be able to allocate and de-allocate memory using 32-bit linear addresses. These library routines must be MP safe and use the PASCAL calling convention.
• The system should be modified to supply what we call “auto thunking”. Auto thunking makes all the conversions from 16-bit pointers and stacks to 32-bit, and the reverse. A 16-bit device driver should always receive 16-bit pointers, while a 32-bit driver will always receive 32-bit pointers (Pointers which are passed inside private data structures are not automatically converted).
• OS/2 must supply a GUI-based configuration utility capable of displaying and editing the configuration file.
• A development kit must be supplied that contains accurate documentation on how to convert 16-bit device drivers, as well as the appropriate header files, make files, debugging kernel, and library support software.

Conclusions

It is our assessment that although this model will work, the device driver conversion effort is minimal when compared with the effort necessary to modify OS/2 to accommodate the new design. The biggest problem is that the underlying file system is still 16-bit, and flattening the file system is not a trivial task. We estimate that the file system alone could take one man-year or more of effort, and a lengthy additional period of integration testing with many different drivers and system configurations.