Vitus Jensen wrote in a message to Patrick Haller:

 MB>> The closest you can come to accomplishing this is to have the
 MB>> driver allocate some memory with DevHelp_VMAlloc() and then make
 MB>> it visible in process address space with
 MB>> DevHelp_VMGlobalToProcess().  

 PH> How can I go the other way round ?

 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> The system converts the 0:32 pointer passed to DosDevIOCtl
 VJ> to a 16:16 pointer usable during the ioctl.

The selector is a synthetic LDT entry, valid only for the duration of the call.

 VJ> Pointers inside that datapacket (pointer to pointer, ugly) have 
 VJ> to be translated by the driver.

Yes, but this is the only way to give the driver the address of a block
longer than 64 KB, and this is often necessary.

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

This is not true of the parameter and data packets.  Until the return from
the strategy routine, a simple lock can be asserted using the virtual
address containing the synthetic selector.  It is critical that the driver
not return from the strategy routine with this lock still asserted, or the
system will hang.  Only if there is a need to access the buffers from
interrupt context is there a need to map GDT selectors for the parameter
and data packets.

Of course, if you mean that it is necessary to map a GDT selector for
access to a block whose address was passed inside the parameter or data
packets, then you are completely correct.

 VJ> Any databuffer should be checked via DevHelp_VerifyAccess.

Well, this is problematic.  As we were discussing in another context, you
can always call DevHelp_VerifyAccess on parameter and data packets if you
are in a new format driver and get a new format IOCtl request packet with
non-zero values for length codes tacked onto the end.  However, since the
selector the driver is seeing to address the parameter and data packets is
a synthetic LDT selector which has been created by the kernel in the course
of the call, the only thing that needs to be checked is length, and this is
implied by a successful return from the lock operation.

In practice, it is a good idea to call DevHelp_VerifyAccess if you have any
idea of what length you are expecting, as I have found that a number of odd
problems are avoided this way.  There is a bug in Borland C++ for OS/2 2.0
malloc() which will cause intermittent failures.  Other compilers seem to
work fine, and Borland will work if DosAllocMem() is used directly to
allocate the buffers for an IOCtl call, but DevHelp_VerifyAccess will
sometimes trap and kill the application because it doesn't like the IOCtl
buffers from malloc().
 
-- Mike


---