PATH ADC Home > Documentation > Hardware > Device Managers and Drivers > PCI Card Services > Designing PCI Cards and Drivers for Power Macintosh Computers

  

---

Native Driver Differences

For detailed information about constructing native device drivers, see Writing a Generic Device Driver later in this chapter. If you are already familiar with writing 68K device drivers, the following are highlights of the principal differences:

• A native driver receives its parameters through the single DoDriverIO entry point, subject to the calling conventions specified by the PowerPC run-time architecture. If a DoDriverIo routine is written in C, the correct behavior is guaranteed. This is a fundamental change from the way 68K drivers received parameters.
• A native driver doesn't have access to its driver control entry (DCE) in the unit table.
• ImmediateIOCommandKind is passed in the ioKind parameter to specify that a request must be executed immediately. If so, the driver must process the request completely and the result of the process must be reflected in the return value from the driver. kInitializeCommand, kFinalizeCommand, kOpenCommand, kCloseCommand, kKillIOCommand, kReplaceCommand, and kSupersededCommand calls are always immediate.
• If the ioKind parameter is either SynchronousIOCommandKind or AsynchronousIOCommandKind, the return value from the driver is ignored. The driver must call IOCommandIsComplete at some future time.
• The Initialize and Finalize commands are sent to the driver as its first and last commands. Initialize gives the driver information it needs to start up. Finalize informs the driver that the system needs to unload it.
• Drivers now receive all OpenDriver and CloseDriver calls, which connect the driver independently of initialization and finalization. In the past, the first (and only) OpenDriver and CloseDriver calls were used as the initialization and finalization mechanism.
• All native drivers must accept and respond to all command codes. The Read_Enable, Write_Enable, Control_Enable, and Status_Enable bits in the DCE are ignored. Native drivers must keep track of I/O permissions for each instance of multiple open actions and return error codes if the permissions are violated.
• The Device Manager processes zero-length reads and writes on behalf of the 68K driver. Native drivers must accept zero-length read and write commands and respond to them in an intelligent way without crashing.
• KillIO is no longer a control call; it is now its own command. For backward compatibility, the Device Manager converts KillIO traps into KillIO commands. It passes the old csKillcode control call ( csCode = 1) without acting on it.
• The Code Fragment Manager sends CFM initialization and termination calls to a driver when the driver is loaded and unloaded. The CFM initialization routine, if present, will run prior to the driver being initialized by the Device Manager. It is possible that the driver will be loaded and its CFM initialization routine run even though it is never opened and, therefore, never closed. It is important that any processing done by a CFM initialization routine be undone by the CFM termination routine. The Device Manager may load a number of drivers looking for the best candidate for a particular device. Only the best driver is opened and remains loaded. All other CFM connections are closed, causing the CFM termination routine to run.
• Native drivers never jump to the IODone routine. To finish processing an I/O request, a generic native driver must call IOCommandIsComplete to notify the Device Manager that a given request has been completed.
• To determine the kind of request or kind of command, the ioTrap field of the old Device Manager parameter block has been replaced with routine parameters called theCode and theKind. Native drivers do not need to read or modify this field.
• A native driver must be reentrant to the extent that during any call from the driver to IOCommandIsComplete the driver may be reentered with another request. 68K device drivers would typically JMP to to IODone and therefore technically never be re-entered.
• A native device driver does not have any sort of header. It must however, export a data symbol called TheDriverDescription. A driver uses this data structure to give header-like information to the Device Manager. The Device Manager uses the information in TheDriverDescription to set the dCtlFlags field in the driver's DCE.
• Native drivers should never look at or modify directly the iodesrbl field of the Device Manager parameter block. (what's that field?)
• A native device driver cannot make use of the dCtlEMask and dCtlMenu fields of its DCE.
• If you set the ioBuffer field in an I/O parameter block to NULL, the Device Manager will not pass the buffer to a native driver (but it will not return an error either).
• Native drivers cannot be used for creating desk accessories.