Summarizing STREAMS Device Drivers

STREAMS device drivers are in many ways similar to non-STREAMS device drivers. The following points summarize the differences between STREAMS drivers and other drivers:

• Drivers must have attach(9E) and probe(9E) entry points to initialize the driver. The attach routine initializes the driver. Software drivers usually have little to initialize, because there is no hardware involved.

• Drivers have open(9E) and close(9E) routines.

• Most drivers have an interrupt handler routine. The driver developer is responsible for supplying an interrupt routine for the device's driver. In addition to hardware interrupts, the system also supports software interrupts. A software interrupt is generated by calling ddi_trigger_softintr(9F).

• All minor nodes are generated by ddi_create_minor_node(9F).

STREAMS device drivers also are similar to STREAMS modules. The following points summarize some of the differences between STREAMS modules and drivers.

• Messages that are not understood by the drivers should be freed.

• A driver must process all M_IOCTL messages. Otherwise, the stream head blocks for an M_IOCNAK, M_IOCACK, or until the timeout (potentially infinite) expires.

• If a driver does not understand an ioctl(2), an M_IOCNAK message must be sent upstream.

• The stream head locks up the stream when it receives an M_ERROR message, so driver developers should be careful when using the M_ERROR message.

• A hardware driver must provide an interrupt routine.

• Multithreaded drivers must protect their own data structures.

For more information on global driver issues and non-STREAMS drivers, see Writing Device Drivers.