All of the example drivers that we've seen until now have had an important feature missing: they never had to wait for anything. So far, a driver's response to a system call has always been immediately available--allowing the driver to response immediately. However, real devices are often not that lucky: they usually have to wait for something to happen before completing a client's system call. For example, a driver might be waiting for data to arrive from the serial port or over the network, or even waiting for a user action.
In situations like this, a basic capability most device drivers must have is the ability to block the caller. Blocking operations are important because they provide a simple interface to user programs that does flow control, rather than something more expensive like continuous polling. For example, user programs expect to be able to execute a statement like read(fd, buf, sizeof(buf)), and expect the read call to block (stop the flow of the calling program) until data is available. This is much simpler and more efficient than polling repeatedly.
In the following sections, we'll describe how to block and unblock system calls for devices that use FUSD.