Hi Mike,

 -=> On 06 Jun 96  16:57:29 Mike Bilow said to Andrew Grillet <=-

 AG> I have used a far pointer for the IORB - why is this bad?

 MB> Certain operations require that the IORB or things pointed to by it be
 MB> near.  As a practical matter, the only reasonable way to handle
 MB> passing such things as SCSI status blocks is to tack them onto the end
 MB> of an IORB and pass the extended IORB as if it was a conventional
 MB> IORB. 

Thanks - a good solution. 

 MB> Applications should not be generating IORBs.  An IORB is a data
 MB> structure used by the storage device drivers to communicate with each
 MB> other.  

I was not thinking clearly when I posted last time. But what I had in mind
was the parameter block to an IOCTL. Presumably this has to be copied
by the system anyway for the ring transition. 

 MB> In general, an IORB is allocated by and is considered owned by
 MB> a DMD.  

None of the systems I have written PDDs for have a DMD. Perhaps they should, but
they don't. We are talking about:

a) Parallel port tape (SCSI)

b) Parallel port IEE-488

c) Video in a window

 MB> An IORB also has special addressing concerns.  It must be absolutely
 MB> fixed in physical memory, and cannot be swapped or even moved.  It
 MB> must be accessible regardless of driver mode, including an interrupt
 MB> time.  It must be accessible to DMA hardware because it can contain
 MB> DMA structures such as the head of the page list and can be implicated
 MB> in scatter-gather.  While the default data segment of the IORB's owner
 MB> meets all these requirements, considerable manual work would be
 MB> required to allocate space for the IORB anywhere else. 

Where should these considerations be catered for in a system where

a) user mode apps use IOCTL calls?

b) app passes buffer to PDD?

and how?

Andrew
 
... If computers are so smart, how do they get stuck with so much work?
--- Blue Wave/Max v2.12 OS/2 [NR]