The OCB structure contains information on a per-file-descriptor basis. What this means is that when a client performs an open() call and gets back a file descriptor (as opposed to an error indication), the resource manager will have created an OCB and associated it with the client. This OCB will be around for as long as the client has the file descriptor open.
Effectively, the OCB and the file descriptor are a matched pair. Whenever the client calls an I/O function, the resource manager library will automatically associate the OCB, and pass it along with the message to the I/O function specified by the I/O function table entry. This is why the I/O functions all had the ocb parameter passed to them. Finally, the client will close the file descriptor (via close()), which will cause the resource manager to dissociate the OCB from the file descriptor and client. Note that the client's dup() function simply increments a reference count. In this case, the OCB gets dissociated from the file descriptor and client only when the reference count reaches zero (i.e., when the same number of close()s have been called as open() and dup()s.)
As you might suspect, the OCB contains things that are important on a per-open or per-file-descriptor basis. Here are the contents (from <sys/iofunc.h>):
typedef struct _iofunc_ocb { IOFUNC_ATTR_T *attr; int32_t ioflag; SEE_BELOW!!! offset; uint16_t sflag; uint16_t flags; } iofunc_ocb_t;
Ignore the comment about the offset field for now; we'll come back to it immediately after this discussion.
The iofunc_ocb_t members are:
Open mode | ioflag value |
---|---|
O_RDONLY | _IO_FLAG_RD |
O_RDWR | _IO_FLAG_RD | _IO_FLAG_WR |
O_WRONLY | _IO_FLAG_WR |
If you wish to store additional data along with the normal OCB, rest assured that you can extend the OCB. We'll discuss this in the Advanced topics section.