Upgrading Privileged-Code Applications on OpenVMS Alpha and
OpenVMS I64 Systems
A.3 Buffered I/O (BUFIO)
The existing 32-bit Buffered I/O (BUFIO) packet format will continue to be
supported. In addition, a new 64-bit BUFIO packet format will be supported.
These BUFIO packets are "self identifying". That is, it is possible
to distinguish a 32-bit from a 64-bit format BUFIO packet from information
in the packet.
Although the structure type code DYN$C_BUFIO is defined and there is an expected
layout for the header of buffered I/O packet, there currently is no formal
definition of a structure. Existing code in drivers and IOCIOPOST.MAR uses
numeric constants as offsets.
The existing 32-bit BUFIO packet will be formally defined along with a new
64-bit BUFIO packet format. The 64-bit BUFIO structure format will also be
used for 64-bit diagnostic buffer packets (see Table
A-3).
Table A-3 BUFIO Packet
| Field |
Type |
Comments |
| bufio$ps_pktdata |
void * |
Pointer to the buffered data within the packet. |
| bufio$ps_uva32 |
void * |
32-bit pointer to user's address space. On a read function, data is
transfered from that user virtual address to the buffer packet during FDT
processing. On a write function, data is transfered to that user virtual
address from the buffer packet during I/O Postprocessing. If this cell
contains the value BUFIO$K_64 (-1), then the pointer to the user buffer
is in bufio$pq_uva64 . |
| bufio$w_size |
unsigned short |
Size of the BUFIO packet in bytes. |
| bufio$b_type |
unsigned char |
Nonpaged pool packet type code, DYN$C_BUFIO |
| BUFIO$K_HDRLEN32 |
constant |
Size in bytes of the minimal buffered I/O packet header with a 32-bit
user virtual address (12). |
| bufio$pq_uva64 |
VOID_PQ |
64-bit pointer to user's address space. On a read function, data is
transfered from that user virtual address to the buffer packet during FDT
processing. On a write function, data is transfered to that user virtual
address from the buffer packet during I/O Postprocessing. This cell contains
a valid address only if the bufio$ps_uva32 cell
contains the value BUFIO$K_64 (-1). |
| BUFIO$K_HDRLEN64 |
constant |
Size in bytes of the minimal buffered I/O packet header with a 64-bit
user virtual address (24). |
A.4 Complex Chained Buffer (CXB)
The CXB structure defines the format of entries that are linked together to
build a complex chained buffered I/O packet.
The CXB structure will be enhanced such that it can be used by existing code
with no source changes to support a 32-bit caller's buffer address. However,
the same enhanced CXB structure can be used to support a 64-bit caller's buffer
address as well (see Table A-4).
Table A-4 CXB Structure Changes
| Field |
Type |
Comments |
| cxb$ps_pktdata |
void * |
Pointer to the buffered data within the packet. This cell will be overlaid
on the existing cxb$l_fl cell to reflect
its current alternate use. |
| cxb$ps_uva32 |
void * |
32-bit pointer to user's address space. If this cell contains the value
BUFIO$K_64 (-1) then the pointer to the user buffer is in cxb$pq_uva64 .
This cell will be overlaid on the existing cxb$l_bl cell
to reflect its current alternate use. |
| cxb$pq_uva64 |
VOID_PQ |
64-bit pointer to user's address space. This cell contains a valid address
only if the cxb$ps_uva32 cell contains
the value BUFIO$K_64 (-1). This cell will be inserted as the last aligned
quadword just before the end of the standard CXB header which is CXB$K_LENGTH
bytes long. |
A.5 Data Chain Block (DCBE)
The DCBE structure is the Data Chain Block that is used by the OpenVMS LAN
driver VMS Communications Interface (VCI). A DCBE is used to connect to a VCRP
all or part of the data to be transmitted. A chain of DCBEs is used when the
data is contained in more than one discontiguous buffer in virtual memory.1
There are two mutually exclusive methods that a DCBE can use to identify the
start of the buffer:
- When thedcbe$l_buffer_address cell contains
a zero, the buffer address is specified by thedcbe$l_svapte anddcbe$l_boff cells.
A fixed-size primary DIOBM structure will be added to the DCBE. This embedded
DIOBM structure is available for use by an upper-level VCM if it needs to
derive a 32-bit SVAPTE from a 64-bit VA_PTE for the PTEs that map the buffer.
The lower-level VCM will not alter this embedded DIOBM or make any assumptions
about it.
- When thedcbe$l_buffer_address cell contains
the a non-zero value, this value is the system virtual address of the buffer.
This method remains unchanged.
Because a VCRP can also be used as a DCBE, the named DCBE cells must be at
the same offsets as their VCRP counterparts. Therefore, DCBE changes are reflected
in the VCRP and changes to the common portion of the VCRP are reflected in
the DCBE.
In addition, SYS$PEDRIVER overlays a DCBE with thevcrp$t_internal_stack area
within the VCRP. Therefore, an increase in the size of the DCBE must be reflected
by a corresponding increase in the size of the internal stack area within the
VCRP (see Table A-5).
Table A-5 DCBE Structure Changes
| Field |
Type |
Comments |
| dcbe$l_reserved |
int32[13] |
This existing vector of 6 filler longwords has been increased to 13
fill longwords to reflect the increased size of the common portion of the
VCRP. The common portion of the VCRP has been increased to accommodate
either an ACB64 or ACB structure. |
| dcbe$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 dcbe$l_buffer_address cell
which continues to be used by lower-level VCMs. The dcbe$pq_buffer_addr64 cell
has been added after the dcbe$l_bcnt cell. |
| dcbe$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 dcbe$l_svapte cell.
This structure has been added just before the end of the DCBE header. |
Note
1 The DCBE should not be confused with
the similarly named DCB structure. The DCB is used internally by the
DECnet Phase IV NETDRIVER. As described in Section
2.2.3, the dcb$l_svapte cell value will be derived from the irp$l_svapte
cell in the associated IRP and will rely on the DIOBM that is embedded
in the IRP. For this reason there is no need for an embedded DIOBM
in the DCB structure.
|
|
