Hello Mike,

13.03.97 23:32, you wrote a message to Vitus Jensen:

...
 PH>> Application allocates a memory buffer in process space and issues
 PH>> an ioctl() passing that pointer to my driver. How has that passed
 PH>> address to be converted so the driver can fill my application's
 PH>> buffer ?
...

 VJ>> If data has to be accessable at any time it has to be locked, a
 VJ>> GDT selector has to be allocted and mapped.

 MB> This is not true of the parameter and data packets.  Until the
 MB> return from the strategy routine, a simple lock can be asserted
 MB> using the virtual address containing the synthetic selector.  
...
 MB> Only if there is a need to access the buffers from interrupt
 MB> context is there a need to map GDT selectors for the parameter
 MB> and data packets.
...

In which case do I need which calls?  Is the following correct for data and 
parameter packets?

Only accessed in the strategy routine (w/o blocking)
- no lock, no GDT selector

Only accessed in the strategy routine (w/ blocking)
- no lock, no GDT selector

Accessed from interrupt context
- locked
- GDT selector mapped

Accessed from first party DMA
- locked
- physical address calculated

I aggree with you when it comes to data buffers passed indirectly.


 VJ>> Any databuffer should be checked via DevHelp_VerifyAccess.

 MB> Well, this is problematic.  As we were discussing in another
 MB> context, you can always call DevHelp_VerifyAccess on parameter
 MB> and data packets if you are in a new format driver and get a new
 MB> format IOCtl request packet with non-zero values for length codes
 MB> tacked onto the end.

I think it's ok to assume a new format IOCtl request if you are writing a 
completely new device driver as you can insist of people using 16bit 
DosDevIOCtl2 or 32bit.
Replacing an existing driver is another story.


 MB> However, since the selector the driver is seeing to address the
 MB> parameter and data packets is a synthetic LDT selector which has
 MB> been created by the kernel in the course of the call, the only
 MB> thing that needs to be checked is length, and this is implied by
 MB> a successful return from the lock operation.
...
I wonder if I wrote wrong code all my life: see above lock vs. non-lock table.

C-x C-s
    Vitus [Team OS/2 Germany #835]

--- Sqed/rexx 95:
(2:2474/424)

--- Squish/386 v1.11