Specifications

Writing FDT Routines
5.4 FDT Routines for System Buffered I/O
5.4.1 Checking Accessibility of the Users Buffer
First the FDT routine invokes the CALL_READCHK or CALL_WRITECHK
macros (which call EXE_STD$READCHK or EXE_STD$WRITECHK,
respectively) to confirm write or read access to the user’s buffer. Both of these
routines write the transfer byte count into IRP$L_BCNT. EXE_STD$READCHK
also sets IRP$V_FUNC in IRP$L_STS to indicate that it is a read function.
5.4.2 Allocating the System Buffer
Next, the FDT routine allocates a system buffer in the following manner:
1. It adds 12 bytes to the byte count passed in the p2 argument of the users I/O
request (obtained from IRP$L_QIO_P2), thus accommodating the standard
size of a system buffer header. This is the total system buffer size.
2. It issues a JSB to EXE$DEBIT_BYTCNT_ALO to ensure that the job has
sufficient remaining byte count quota to allow its use of the requested buffer.
If the job has sufficient quota, EXE$DEBIT_BYTCNT_ALO allocates the
requested buffer from nonpaged pool, writes the buffer’s size and type into its
third longword, and subtracts the system buffer size from JIB$L_BYTCNT.
The operating system also supplies the routines EXE$DEBIT_BYTCNT_BYTLM_
ALO, EXE$DEBIT_BYTCNT(_NW), EXE$DEBIT_BYTCNT_BYTLM(_NW), and
EXE_STD$ALLOCBUF, which perform the same type of work as EXE$DEBIT_
BYTCNT_ALO. These routines are fully described in the OpenVMS VAX Device
Support Reference Manual.
Once the buffer is allocated, the FDT routine takes the following steps:
1. Loads the address of the system buffer into IRP$L_SVAPTE.
2. Loads the total size of the system buffer into IRP$L_BOFF.
3. Stores the starting address of the system buffer data area in the first
longword of the buffer header.
4. Stores the user’s buffer address in the second longword of the header.
5. Copies data from the user buffer to the system buffer if the I/O request is a
write operation.
At this point, the buffers are ready for the transfer. Figure 5–1 illustrates the
format of the system buffer.
5.4.3 Buffered-I/O Postprocessing
When the transfer finishes, the driver returns control to the operating system for
completion of the I/O request. The driver writes the final request status in the
low-order word of R0. Use of the high-order word of R0 and the longword of R1 is
driver specific. Certain drivers use these fields to report a transfer byte count, for
example.
The driver must leave the buffer header intact; I/O postprocessing relies on the
header’s accuracy. When system I/O postprocessing gains control, it performs
three steps:
1. Issues a JSB instruction to EXE$CREDIT_BYTCNT to add the value in
IRP$L_BOFF to JIB$L_BYTCNT, thus updating the user’s byte count quota.
5–8