Vitus Jensen wrote in a message to Mike Bilow:

 VJ> I'm familiar with device drivers in general and especially
 VJ> OS/2 physical ones. I'm writing a filter driver to
 VJ> START/STOP SCSI disks when they haven't beed accessed for
 VJ> some time.  This works very well.

 VJ> To let the user change timeout values w/o reboot I defined
 VJ> some IOCtls to get/change the device list.  Application
 VJ> passes a large buffer (ex. room for 32 devices) and the
 VJ> driver returns how much it has filled.  The usual design. 

 VJ> Now: how can the filter modifiy parmlen and/or datalen in
 VJ> the above call?  No DDK sample uses this possibility and the
 VJ> is no documentation. :-( 

 VJ> Could you enlighten me?

You cannot from within the driver modify the length of the parameter and
data packets passed on the DosDevIOCtl() call.  These packets are owned by
the caller, and the callee has no business changing their lengths.

The closest you can come to accomplishing this is to have the driver
allocate some memory with DevHelp_VMAlloc() and then make it visible in
process address space with DevHelp_VMGlobalToProcess().  Since the driver
will now own dynamically allocated memory associated with the calling
process, then the driver must take pains to enforce open/close protocol in
order to avoid a memory leak.  If your driver may need access to the memory
in a context-free situation, as when in an interrupt handler, then you will
have to provide dual addressibility so that the memory is allocated with
the VMDHA_PROCESS flag unasserted and then mapped into process address
space separately.  Finally, the driver will have to manage locking and so
forth manually, as with any other area allocated using DevHelp_VMAlloc(),
and this can be a pain if the area is large and declared swappable.

If the driver owns memory, it should be able to concoct a process linear
address that can be passed back up to the calling application in the
parameter or data packet.  That is, only the address of the new block need
be passed up, and the pointer is itself of fixed size.

This is quite a lot of effort and complexity to go through, in my opinion,
to accomplish your overall goal.  Since you have a system imposed limit of
56 units, you could simply allocate a fixed buffer adequate to store 56
entries.  When you say "a large buffer," how large do you mean? 
Anything 64 KB or smaller would not require the elaborate dance of pointers
I discuss above, but running over 64 KB would.  The system I describe is
more appropriate for a situation in which this level of complexity cannot
be avoided, such as in a video driver.
 
-- Mike


---