|
|
A control block optionally defines additional space that may be used by the driver to store information related to a channel operation request. This space is referred to as the ``scratch space'' of the control block and its contents are determined by the driver. Scratch space is accessed via a scratch pointer in the control block.
Scratch space is transferred as part of the control block to another region during a channel operation. When this occurs, the region on the other end of the channel takes ownership of the scratch space, and so its contents may not be preserved when the control block is returned. (Note that the contents of the scratch space are preserved, however, on return from an asynchronous service call to the UDI environment. See Asynchronous Service Calls in the Core Specification.)
For the udi_cmos driver, this pointer is contained in the ``bus_bind_cb'' structure. This segment of the driver module source defines what the scratch area for bus_bind_cb will look like.
cmos_udi.c sample code (cont.) |
---|
/* * Scratch structures for various control block types. */ typedef struct { udi_ubit8_t addr; /* CMOS device address */ udi_ubit8_t count; /* # bytes to transfer */ } cmos_gio_xfer_scratch_t; |
pseudod.c sample code (cont.) |
NOTE: The pseudod driver uses no scratch space.
|
The udi_cmos driver reads and writes CMOS RAM values. The scratch space for the control block used when communicating with the device is a structure containing two unsigned 8-bit values: a CMOS address and a byte count, (For a discussion of UDI data types, see in the Core Specification.)
After defining the cmos_gio_xfer_scratch_t structure type, two offsets are defined for the addr and count values contained in the scratch buffer.
What follows is a series of #define statements declaring the scratch space requirements for each control block type used in the driver code. These are used in the control block structure definitions that follow.