Andrew Grillet wrote in a message to Mike Bilow:

 MB> You can figure them out yourself or study the IBM source 
 MB> examples, but is not explicitly stated that the tail end of 
 MB> memory space after an IORB is valuable for use as a status 
 MB> block or other structure. MS C 6.0 also achieves powerful 
 MB> optimizations if the IORBs are allocated on a power-of-two 
 MB> boundary, such as 128 or 256 bytes, with the slack space used 
 MB> as described. These are really tricks to take advantage of the 
 MB> compiler, but most device driver programmers do not know them. 

 AG> Coming from DOS, I was thinking that the IORB is memory in
 AG> the caller's address space. I realse that OS/2 must actually
 AG> make a copy, but how can yiou be sre that the IORB is bigger
 AG> than the particular IOReqst requires? And how much bigger?
 AG> And for how many future upgrades? 

An I/O Request Block ("IORB") is an internal control structure
that is never seen by applications.  The idea is that an application makes
some sort of API call which implicates the I/O subsystem, such as
DosOpen(), DosRead(), DosDevIOCtl(), and so on.  The kernel allocates a
Request Packet ("RP") from its fixed memory pool and passes the
address of the RP to the device driver in the ES:BX register pair.

The device driver then parses the RP and determines what the kernel is
asking it to do on behalf of the application.  Depending upon the type of
request and the particular API call used by the application, the RP may
contain addresses of buffers owned by the application.  These addresses may
either be virtual addresses and subject to explicit locking in the case of
DosDevIOCtl() -- since parameter buffers and data buffers are free format,
they can contain other addresses as defined by the private interface to the
device driver -- or may be physical addresses which have been implicitly
locked by the kernel in the case of DosRead() and DosWrite().

The device driver receiving the RP may then allocate its own IORBs in order
to perform low-level I/O operations.  An IORB is not the buffer for moving
actual data between the application and the device, but is rather the
control structure for communication between the Device Managers (DMDs) and
the filters and adapter drivers (FLTs and ADDs).  For example, the DMD
might be responsible for making the application buffer accessible by
constructing a page list of locked physical memory addresses and then
passing that page list via the IORB so that the ADD can do scatter-gather
DMA directly to or from the application buffer.

OS/2 goes to great lengths to prevent copying of actual I/O data, and to
minimize the overhead of I/O operations.  Throughout the whole API-RP-IORB
hierarchy, only the addresses of data buffers are typically transferred. 
The complexity arises from the need for memory to be accessible in
different contexts and in different addressing modes.  What an application
sees as process linear memory is not only freely moveable, but also
swappable.  The device drivers need to lock these ranges under various
constraints to prevent them from being moved or swapped, and may also need
to construct global virtual addressability for the same memory.  Further
down, DMA hardware is going to need physical addressability for the memory,
but the region may actually be stored discontiguously in real memory, in
which case a page list must be created.  Still, these are all just
addresses for the same memory, and only the addresses are passed up and
down the chain.

 AG> If its a popular sport to do this, then presumably IBM will
 AG> have to support it in future releases. If so, documentation
 AG> will be required. Please can we know?

Using slack space on the end of an IORB is really more of a programming
technique than a system facility.  It makes things a lot easier, and is the
kind of thing that looks obvious once you have seen it done. 
Unfortunately, nothing in the offical IBM documentation suggests doing it,
although all of the IBM device driver programmers use the technique. 
Fortunately, the IBM DDK provides well-commented source code for most of
the important device drivers in OS/2, and studying these provides better
information, although in a very inconvenient form, than you can get
anywhere else.
 
-- Mike


---