Native Driver Implementation

Apple Confidential Information 1 Native Drivers for PCI and other Peripherals in Marconi April 13, 1994 Please direct all comments to: Wayne Meretsky AppleLink: WNM Extension: 4-2955 Apple Confidential Information 2 Scope This document includes the design and implementation plan for allowing entirely native device drivers to be used with Marconi. Summary It is difficult to explain to third party developers of peripheral equipment exactly why the only implementation option available for writing a device driver precludes native code. Combined with the move away from NuBus and towards PCI, the developer story is poor. To entice card developers to create Macintosh devices and to simplify the transition to a Modern Operating System, a native driver model has been designed that will allow native drivers to seamlessly integrate with System Software. Finally, Apple must guarantee that these native drivers will continue to function well with future releases of system software including Maxwell. Approach Marconi will include a new Device Manager that supports a new format for device drivers. Attempts to open a device driver will cause the Device Manager to look for this new driver format in addition to the presently defined 'DRVR' described by Inside Macintosh Volume II, Chapter 6. Device Manager Support The process of locating device drivers during startup does not presently utilize the Device Manager's OPEN service because that service does not provide sufficient control over the exact loading and initialization process that is required by system startup. In fact, it is widely held that the Device Manager's OPEN service is never called to open any driver because the behavior defined by OPEN is always inappropriate. Due to the added complexity of opening native drivers, the entire process of locating a driver, loading it into memory, and initializing the driver's related data structures will be packaged into a new externally defined and supported API extension to the Device Manager. All system software that presently loads and installs drivers into the system must be changed to utilize this new service if they are to be capable of supporting native device drivers. In addition to changes to support native drivers, the Device Manager will provide a new flavor of IODone to greatly simplify the life of many driver writers. This spin of request completion, IORequestDone, allows the driver to specify which request has completed. The parameter block is presumed to be located Apple Confidential Information 3 somewhere on the device control block's list of outstanding requests rooted by the dCtlQHdr but, unlike IODone, it need not be the first request on that queue. The new API is as follows: void IORequestDone (DCtlPtr theDce, ParmBlkPtr thePb, OSErr theResult); Native Device Driver Description Device drivers are best characterized by three general properties: • Container format • API exported from driver to system • API imported by driver from sys…