Skip Navigation Links | |
Exit Print View | |
Writing Device Drivers Oracle Solaris 11.1 Information Library |
Part I Designing Device Drivers for the Oracle Solaris Platform
1. Overview of Oracle Solaris Device Drivers
2. Oracle Solaris Kernel and Device Tree
5. Managing Events and Queueing Tasks
7. Device Access: Programmed I/O
10. Mapping Device and Kernel Memory
13. Hardening Oracle Solaris Drivers
14. Layered Driver Interface (LDI)
Part II Designing Specific Kinds of Device Drivers
15. Drivers for Character Devices
Overview of the Character Driver Structure
Character Device Autoconfiguration
Device Access (Character Drivers)
open() Entry Point (Character Drivers)
close() Entry Point (Character Drivers)
Differences Between Synchronous and Asynchronous I/O
ioctl() Entry Point (Character Drivers)
I/O Control Support for 64-Bit Capable Device Drivers
32-bit and 64-bit Data Structure Macros
How Do the Structure Macros Work?
Declaring and Initializing Structure Handles
Operations on Structure Handles
18. SCSI Host Bus Adapter Drivers
19. Drivers for Network Devices
Part III Building a Device Driver
22. Compiling, Loading, Packaging, and Testing Drivers
23. Debugging, Testing, and Tuning Device Drivers
24. Recommended Coding Practices
B. Summary of Oracle Solaris DDI/DKI Services
C. Making a Device Driver 64-Bit Ready
A thread sometimes needs to handle I/O on more than one file descriptor. One example is an application program that needs to read the temperature from a temperature-sensing device and then report the temperature to an interactive display. A program that makes a read request with no data available should not block while waiting for the temperature before interacting with the user again.
The poll(2) system call provides users with a mechanism for multiplexing I/O over a set of file descriptors that reference open files. poll(2) identifies those file descriptors on which a program can send or receive data without blocking, or on which certain events have occurred.
To enable a program to poll a character driver, the driver must implement the chpoll(9E) entry point. The system calls chpoll(9E) when a user process issues a poll(2) system call on a file descriptor associated with the device. The chpoll(9E) entry point routine is used by non-STREAMS character device drivers that need to support polling.
The chpoll(9E) function uses the following syntax:
int xxchpoll(dev_t dev, short events, int anyyet, short *reventsp, struct pollhead **phpp);
In the chpoll(9E) entry point, the driver must follow these rules:
Implement the following algorithm when the chpoll(9E) entry point is called:
if ( /* events are satisfied now */ ) { *reventsp = mask_of_satisfied_events } else { *reventsp = 0; if (!anyyet) *phpp = &local_pollhead_structure; } return (0);
See the chpoll(9E) man page for a discussion of events to check. The chpoll(9E) entry point should then return the mask of satisfied events by setting the return events in *reventsp.
If no events have occurred, the return field for the events is cleared. If the anyyet field is not set, the driver must return an instance of the pollhead structure. The pollhead structure is usually allocated in a state structure. The pollhead structure should be treated as opaque by the driver. None of the pollhead fields should be referenced.
Call pollwakeup(9F) whenever a device condition of type events, listed in Example 15-10, occurs. This function should be called only with one event at a time. You can call pollwakeup(9F) in the interrupt routine when the condition has occurred.
Example 15-10 and Example 15-11 show how to implement the polling discipline and how to use pollwakeup(9F).
The following example shows how to handle the POLLIN and POLLERR events. The driver first reads the status register to determine the current state of the device. The parameter events specifies which conditions the driver should check. If an appropriate condition has occurred, the driver sets that bit in *reventsp. If none of the conditions has occurred and if anyyet is not set, the address of the pollhead structure is returned in *phpp.
Example 15-10 chpoll(9E) Routine
static int xxchpoll(dev_t dev, short events, int anyyet, short *reventsp, struct pollhead **phpp) { uint8_t status; short revent; struct xxstate *xsp; xsp = ddi_get_soft_state(statep, getminor(dev)); if (xsp == NULL) return (ENXIO); revent = 0; /* * Valid events are: * POLLIN | POLLOUT | POLLPRI | POLLHUP | POLLERR * This example checks only for POLLIN and POLLERR. */ status = ddi_get8(xsp->data_access_handle, &xsp->regp->csr); if ((events & POLLIN) && data available to read) { revent |= POLLIN; } if (status & DEVICE_ERROR) { revent |= POLLERR; } /* if nothing has occurred */ if (revent == 0) { if (!anyyet) { *phpp = &xsp->pollhead; } } *reventsp = revent; return (0); }
The following example shows how to use the pollwakeup(9F) function. The pollwakeup(9F) function usually is called in the interrupt routine when a supported condition has occurred. The interrupt routine reads the status from the status register and checks for the conditions. The routine then calls pollwakeup(9F) for each event to possibly notify polling threads that they should check again. Note that pollwakeup(9F) should not be called with any locks held, since deadlock could result if another routine tried to enter chpoll(9E) and grab the same lock.
Example 15-11 Interrupt Routine Supporting chpoll(9E)
static u_int xxintr(caddr_t arg) { struct xxstate *xsp = (struct xxstate *)arg; uint8_t status; /* normal interrupt processing */ /* ... */ status = ddi_get8(xsp->data_access_handle, &xsp->regp->csr); if (status & DEVICE_ERROR) { pollwakeup(&xsp->pollhead, POLLERR); } if ( /* just completed a read */ ) { pollwakeup(&xsp->pollhead, POLLIN); } /* ... */ return (DDI_INTR_CLAIMED); }