HP OpenVMS Systems Documentation |
Upgrading Privileged-Code Applications on OpenVMS Alpha and OpenVMS I64 Systems
B.5 EXE_STD$MODIFY, EXE_STD$READ, EXE_STD$WRITEThe routines EXE_STD$MODIFY, EXE_STD$READ, and EXE_STD$WRITE are upper-level FDT routines, so their interfaces remain unchanged:
These routines obtain the address of the caller's buffer fromirp->irp$l_qio_p1.
These routines have been modified to obtain the full 64-bit buffer address
fromirp->irp$q_qio_p1and pass it to EXE_STD$READLOCK
or EXE_STD$WRITELOCK. Note, however, that the buffer size remains a longword
and is obtained fromirp->irp$l_qio_p2 without
checking the upper 32-bits.
The routines EXE_STD$MODIFYLOCK, EXE_STD$READLOCK, and EXE_STD$WRITELOCK are FDT support routines that:
If an error is encountered, an optional error callback routine is invoked and the I/O request is aborted. If the entire buffer is not resident then the I/O request is backed out and a special status is returned to request a pagefault of the needed page. In releases prior to OpenVMS Alpha Version 7.0, the interfaces for these routines were:
The new interfaces for these routines are:
There are two differences in the new OpenVMS Alpha Version 7.0 interfaces:
Both of these interface changes are upwardly compatible.
There are six MACRO-32 macros that facilitate the use of the routines described in Section B.6 by code that was originally written to use the JSB-interface counterparts for these routines. These macros have implicit register inputs and outputs that correspond to the register inputs and outputs of the JSB-interface routines. The CALL_MODIFYLOCK, CALL_READLOCK, and CALL_WRITELOCK macros have been modified to pass the full 64-bits of R0 as the buffer address and to omit the optional error routine parameter instead of passing the value 0. The CALL_MODIFYLOCK_ERR, CALL_READLOCK_ERR, and CALL_WRITELOCK_ERR macros have been modified to pass the full 64-bits of R0 as the buffer address. This is an upwardly compatible change to the implementation of these macros.
This change is transparent to users prior to OpenVMS Alpha Version 7.0, because
R0 currently contains the 32-bit buffer address sign-extended to 64-bits.
The routines EXE_STD$READCHK and EXE_STD$WRITECHK probe the accessibility of a specified buffer by the mode contained inirp->irp$b_mode. In releases prior to OpenVMS Alpha Version 7.0, the interfaces for these routines were:
As of OpenVMS Alpha Version 7.0, the new interfaces for these routines are:
The only difference in the new interface is that these functions now use the
full 64-bits of the buffer addressbuf that is
passed by value. Previously, the buffer address was a 32-bit value sign-extended
into a 64-bit parameter value. Thus, this is an upward compatible change to
the interface.
The CALL_READCHK, CALL_READCHKR, CALL_WRITECHK, and CALL_WRITECHKR MACRO-32
macros have been modified to pass the full 64-bits of the buffer address in
a similar fashion as described in Section
B.6.1.
The routines EXE_STD$SETCHAR and EXE_STD$SETMODE are upper-level FDT routines, thus their interfaces remain unchanged:
Both of these routines use the local routine CHECK_SET to obtain and validate
a pointer to the caller's buffer fromirp->irp$l_qio_p1.
The routine CHECK_SET has been modified to obtain the full 64-bit buffer address
fromirp->irp$q_qio_p1. Routines EXE_STD$SETCHAR
and EXE_STD$SETMODE has been modified to use the 64-bit pointer returned by
CHECK_SET when loading the UCB characteristics from the caller's buffer.
Routine IOC_STD$CREATE_DIOBM is a new routine that is used to derive a 32-bit system virtual address for a specific number of PTEs that are pointed to by a 64-bit process virtual address. This routine allocates a "primary" DIOBM structure of sufficient size for its needs and returns a pointer to it. When the derived 32-bit system virtual address is no longer required the DIOBM must be released by calling the IOC_STD$RELEASE_DIOBM routine. The algorithm used by this routine is very similar to the one used by IOC_STD$FILL_DIOBM as described in Section B.10. The significant difference is that IOC_STD$CREATE_DIOBM allocates a sufficiently sized primary DIOBM structure for its needs and does not depend on a preallocated fixed-size DIOBM. This routine is designed for previous users of the MMG$IOLOCK routine that do not have an embedded DIOBM to work with, but can maintain a single pointer to the external DIOBM structure that is returned by IOC_STD$CREATE_DIOBM. The interface for IOC_STD$CREATE_DIOBM is:
Table B-7 summarizes the use of the arguments.
This routine requires system resources, nonpaged pool and possibly SPTEs. If there are insufficient resources, this routine will, by default, place the process (kernel thread) in a kernel mode wait state for nonpaged pool and try again until it succeeds. In this case, the return value of this routine is always SS$_NORMAL because it will not return until it can do so successfully. However, the caller can inhibit this resource wait by setting the DIOBM$M_NORESWAIT option in the flags parameter. When this is done an error status is returned to the caller if there are insufficient system resources. This capability is intended to be used in contexts where either a resource wait in kernel mode is not acceptable or the caller can readily put the process into a wait state in the requestor's mode. This routine must be called in process context and assumes that it was called at IPL 2, or minimally, that it can lower IPL to 2.
|