|
HP OpenVMS systems documentation |
Previous | Contents | Index |
This section describes the additions and changes to cells in the I/O Request Packet Extension (IRPE) structure. An IRPE structure can contain additional driver-specific information that needs to be associated with an IRP. It can also be used to manage additional buffers that are locked down for direct I/O.
If the IRP$M_EXTEND bit is set in irp$l_sts then the irp$l_extend cell contains a pointer to an associated IRPE structure. Similarly, if the IRPE$M_EXTEND bit is set in the irpe$l_sts cell, then the irpe$l_extend cell contains a pointer to another IRPE. In general, if there is an IRPE cell with the name irpe$X and an IRP cell with the name irp$X , then the cells must be at the same offsets such that the IRP and the IRPE can be used interchangeably in contexts that depend only on these common cells.
Currently, a single IRPE structure can be used to keep track of two separate regions of locked down pages. The new IRPE structure can only manage a single region of locked down pages and contains a single fixed-size primary DIOBM structure for that purpose (see Table A-10).
Field | Type | Comments |
---|---|---|
irpe$b_rmod | unsigned char | Requestor's access mode. This corresponds to the irp$b_rmod cell. The space for this IRPE cell was reserved but the cell was not previously formally defined. The addition of this cell facilitates the usage of an IRPE with the EXE_STD$READLOCK routines because the irpe$b_rmod cell is one of the required implicit inputs. |
irpe$l_oboff | unsigned int | Original byte offset into first page for buffer locked into memory. This corresponds to the irp$l_oboff cell that was added to the IRP on OpenVMS Alpha but was not formally defined in the IRPE. This corrects that omission. |
irpe$q_driver_p0 | int64 | Available for use by driver. This cell is overlaid on what was previously filler space. |
irpe$l_driver_p0 | int | Available for use by driver. This cell is overlaid on the low-order 32-bits of irpe$q_driver_p0 . |
irpe$l_driver_p1 | int | Available for use by driver. This cell is overlaid on the high-order 32-bits of irpe$q_driver_p0 . |
irpe$q_driver_p2 | int64 | Available for use by driver. This cell is overlaid on what was previously filler space. |
irpe$l_driver_p2 | int | Available for use by driver. This cell is overlaid on the low-order 32-bits of irpe$q_driver_p2 . |
irpe$l_driver_p3 | int | Available for use by driver. This cell is overlaid on the high-order 32-bits of irpe$q_driver_p2 . |
irpe$pq_va_pte | PTE_PQ | A 64-bit pointer to the actual PTEs that map the user buffer. If the user buffer is not in shared system space, then this PTE virtual address is only valid in the caller's process context. |
irpe$l_svapte | PTE * | A 32-bit pointer to a copy of the PTEs that map the user buffer. If zero, then no PTEs have been locked for this request. This cell replaces the irpe$l_svapte1 cell. |
irpe$l_svapte1 | - | This cell has been removed. It is replaced by the irpe$l_svapte cell. |
irpe$l_bcnt | unsigned int | Byte count for buffer locked into memory. This cell replaces the irpe$l_bcnt1 cell. |
irpe$l_bcnt1 | - | This cell has been removed. It is replaced by the irpe$l_bcnt cell. |
irpe$l_boff | unsigned int | Byte offset into first page for buffer locked into memory. This cell replaces the irpe$l_boff1 cell. |
irpe$l_boff1 | - | This cell has been removed. It is replaced by the irpe$l_boff cell. |
irpe$r_diobm | DIOBM | Embedded fixed-size primary "direct I/O buffer map" structure. This embedded DIOBM structure is valid if and only if the irpe$l_svapte cell contains a non-zero value. See Section A.6 for a complete description of the DIOBM structure. |
irpe$l_svapte2 | - | This cell has been removed. It was used to contain a pointer to the first PTE for a second buffer that was locked into memory. If zero, then there was no second buffer. |
irpe$l_bcnt2 | - | This cell has been removed. It was used for the byte count for the second buffer locked into memory. |
irpe$l_boff2 | - | This cell has been removed. It was used for the byte offset for the second buffer locked into memory. |
This section describes the I/O-specific additions to cells in Process Header (PHD) structure (see Table A-11).
Field | Type | Comments |
---|---|---|
phd$l_iorefc | uint32 | Number of reasons to keep the PHD resident due to groups of pages locked for direct I/O. This count is incremented by MMG_STD$IOLOCK_BUF and decremented by MMG_STD$IOUNLOCK_BUF. On the zero-to-one transition of this cell, the slot reference count for the process in the PHV$GL_REFCBAS_LW vector is incremented. On the one-to-zero transition of this cell, the slot reference count for the process in the PHV$GL_REFCBAS_LW vector is decremented. |
For information about S2DGB 64-bit addressing support, see the OpenVMS Alpha Guide to 64-Bit Addressing and VLM Features2.
2 This manual has been archived but is available on the OpenVMS Documentation CD-ROM. This information has also been included in the OpenVMS Programming Concepts Manual, Volume I. |
A.12 VMS Communications Request Packet (VCRP)
The VCRP structure is the VMS Communications Request Packet that is used by the OpenVMS LAN driver VMS Communications Interface (VCI). A VCRP is used to transfer data between an upper- and lower-level VCM.
The VCRP is designed so that it can be used as an ACB by an upper-level VCM. Therefore, the VCRP has been enhanced such that it can be used either as an ACB or ACB64 structure by an upper-level VCM. This allows upper-level VCMs the flexibility of providing 64-bit AST support at some time in the future without requiring another VCRP change and the forced recompilation of all VCMs (see Table A-12).
Field | Type | Comments |
---|---|---|
vcrp$v_acb_flags_valid | bit | This is a new bit in the vcrp$b_rmod cell that corresponds to the acb$v_flags_valid bit. This bit is available for the exclusive use of upper-level VCMs. |
vcrp$l_acb64x_offset | int | Offset to the ACB64X structure embedded in this VCRP. This cell corresponds to the acb$l_acb64x cell and is overlaid on vcrp$l_ast . This cell is available for the exclusive use of upper-level VCMs. |
vcrp$l_acb_flags | unsigned int | This cell corresponds to the acb$l_flags cell and is overlaid on the first longword of the existing fork block filler space in the VCRP. This cell is available for the exclusive use of upper-level VCMs. |
vcrp$l_thread_id | int | This cell corresponds to the acb$l_thread_pid cell and is on the second longword of the existing fork block filler space in the VCRP. Reserved for use by the Kernel Threads project. |
vcrp$pq_acb64_ast | VOID_FUNC_PQ | This cell corresponds to the acb64$pq_ast cell. This cell is available for the exclusive use of upper-level VCMs. |
vcrp$q_acb64_astprm | int64 | This cell corresponds to the acb64$q_astprm cell. This cell is available for the exclusive use of upper-level VCMs. |
vcrp$q_user_thread_id | uint64 | Unique user thread identifier. Corresponds to the acb64$q_user_thread_id cell. This cell is available for the exclusive use of upper-level VCMs. |
vcrp$pq_buffer_addr64 | VOID_PQ | 64-bit buffer address. This cell is available for use by upper-level VCMs only. Note that this cell does not replace the vcrp$l_buffer_address cell which continues to be used by lower-level VCMs. |
vcrp$r_diobm | DIOBM | Embedded fixed-size primary "direct I/O buffer map" structure. This DIOBM structure is available for use by upper-level VCMs that need to lock down a buffer and provide a value for the vcrp$l_svapte cell. |
vcrp$t_internal_stack | char[220] | This existing internal stack area of 92 bytes has been increased to 220 bytes to reflect the increased size of a DCBE. SYS$PEDRIVER requires that it can place a DCBE within this stack area. This space is available for the exclusive use of upper-level VCMs. |
Previous | Next | Contents | Index |