Vitus Jensen wrote in a message to -all-:

 VJ> an IOCtl call into a driver has to return a variable-length list.
 VJ> To skip to return a header in front of this list (as I have done
 VJ> on previous opportunities) I want to update the application's
 VJ> idea of needed/filled data buffer length.

Sorry, I missed this the first time around.

 VJ> I found a "Device Driver Programming FAQ" at www.wdi.co.uk
 VJ> and it states that returning parameter or data length isn't
 VJ> possible.

 VJ> So I stick with an header in front of the list.  Sad.

I'm familiar with that site, but it is hardly comprehensive.  What is it
that you are trying to do?

When you call down to a device driver using DosDevIOCtl(), OS/2 maps a
temporary selector (usually 0017h) which allows the driver to access the
parameter and data areas.  The driver can modify the contents of these
areas as much as it wants, provided that it takes care to avoid overrunning
the end of the allocated area.

Where you get into significant complexity is if the information passed
inside the parameter or data areas contains a pointer, since the caller and
callee have radically different views of memory.  It is easier for the
device driver to do a series of conversions to get access to the caller's
linear address than the reverse, although both are possible.  There are
also important issues when a device driver wants to look at application
memory, since the object of interest could even be swapped out.

A very simple workaround available if you have control of both the caller
and callee is to define a protocol where the caller queries the driver for
a recommended buffer size, allocates it on behalf of the driver, and then
passes the linear address down via IOCtl or some standard mechanism.

Another option to look at is to use DosRead()/DosWrite() to access the
driver instead of DosDevIOCtl(), since they carry physical rather than
virtual addresses upon arrival and prelock these regions.  (A physical
address would be worthless if it did not pertain to a locked region.)

It's possible to have a driver which maintains a large amount of address
space or even real memory, but you have to be very careful in how you do
it.  For example, a RAM disk driver can have quite a lot of memory
associated with it, provided it is kept swappable and you take care not to
lock more than 64 KB at once.  However, Ring 3 callers should never be
shown such internal memory directly or you will get into concurrency
troubles where multiple callers access the driver's private memory.  While
these kinds of things are possible and I have seen them done, I consider
them to be an abuse of the OS/2 memory protection architecture.
 
-- Mike


---