To illustrate how your resource manager might return data to a client, consider
a simple resource manager that always returns the constant string "Hello, world!\n".
There are a number of issues involved, even in this very simple case:
- Matching of the client's data area size to the data being returned
- In our case, the resource manager is returning a fixed string of 14 bytes—there is exactly
that much data available. This is identical to a read-only file on a disk that contains
the string in question; the only real difference is that this “file” is maintained in
our C program via the statement:
char *data_string = "Hello, world!\n";
The client, on the other hand, can issue a read() request of any size—the client could ask for
one byte, 14 bytes, or more. The impact of this on the read I/O function handler that
you're going to provide is that you must be able to match the client's requested data
size with what's available.
- Handling of the EOF case
- A natural fallout of the way you handle the client's data area size
considerations is the
corner case of dealing with the End-Of-File (EOF) on the fixed string.
Once the client has read the final \n character, further attempts
by the client to read more data should return EOF.
- Maintenance of context information (the lseek() index)
- Both the “Data area size considerations” and the “Handling of EOF case” scenarios will
require that context be maintained in the OCB passed to your read I/O function handler,
specifically the offset member.
- Updating of POSIX stat() information
- One final consideration: when data is read from a resource manager,
the POSIX access time (atime) variable needs
to be updated.
This is so that a client stat()
function will show that someone has indeed accessed the device.