I’m using the Offset member of the OVERLAPPED structure to tell my UMDF USB driver which endpoint to read data from. Then from within the driver I call the function GetReadParameters() to direct the Read to the appropriate endpoint.
My first question is about the 3rd parameter in GetReadParameters(). The documentation doesn’t give a very good explanation for the usage of the variable “pulKey”.
My second question is that I would like to know if it is possible to change any of the OVERLAPPED members from within the driver. Since I’m obtaining a timestamp for the data received in the completion routine, I would like to return this through one of the OVERLAPPED members instead of returning it separately.
>documentation doesn’t give a very good explanation for the usage of the
variable
“pulKey”.
It has nothing to do with OVERLAPPED’s Offset. ByteOffset is what you need.
timestamp for the data received in the completion routine, I would like to
return this
through one of the OVERLAPPED members instead of returning it separately.
No. Add the timestamp as the first word of the output buffer before the actual
data.
Thanks Maxim.
I was trying to avoid embedding additional information into the data stream, but unless I come up with another method I’ll have to consider doing that.
So is there no way to change any of the OVERLAPPED members from within the driver?
I didn’t think the “pulKey” variable would be of any use, but I was just curious what it is there for. Since this is an output, I wanted to know what the corresponding input is.
I’m using the Offset member of the OVERLAPPED structure to tell my UMDF USB driver which endpoint to read data from. Then from within the driver I call the function GetReadParameters() to direct the Read to the appropriate endpoint.
I don’t think that’s a particularly good solution. What happens if an
application opens your driver without using FILE_FLAG_OVERLAPPED?
We solved this by using a driver namespace. To access endpoint #2, the
app opens \.\MyDriver\pipe2. Now, the app can use overlapped or not,
and everything stays straight.
My first question is about the 3rd parameter in GetReadParameters(). The documentation doesn’t give a very good explanation for the usage of the variable “pulKey”.
If you give it the address of a ULONG, the function will give you a hash
code that is unique to this request for the life of the request. They
don’t tell you what the number is. My guess would be something like the
address of the incoming IRP.
My second question is that I would like to know if it is possible to change any of the OVERLAPPED members from within the driver. Since I’m obtaining a timestamp for the data received in the completion routine, I would like to return this through one of the OVERLAPPED members instead of returning it separately.
My understanding is that the OVERLAPPED structure goes both ways, but I
don’t think that’s written down anywhere.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I’m not concerned about the application not opening the driver without FILE_FLAG_OVERLAPPED since I’m also responsible for that part of the application.
I assumed that the OVERLAPPED structure goes both ways too, but I can’t find any documentation reinforcing that belief.
It seems that the value of “Key” is always 0 for me.
> I don’t think that’s a particularly good solution. What happens if an
application opens your driver without using FILE_FLAG_OVERLAPPED?
Then it will be able to set the offset by lseek64/SetFilePointer.
Also, if the driver is written for a dedicated app, this is not the issue.
We solved this by using a driver namespace. To access endpoint #2, the
app opens \.\MyDriver\pipe2. Now, the app can use overlapped or not,
and everything stays straight.
I also think this is a better solution, and very cheap - just check
the ->FileName in MJ_CREATE.
My understanding is that the OVERLAPPED structure goes both ways, but I
don’t think that’s written down anywhere.
Only the IO_STATUS_BLOCK - Internal/InternalHigh - goes both way. It is
Irp->UserIosb.
> It seems that the value of “Key” is always 0 for me.
This is the same key as from UnlockAllByKey and such functions, related to byte
range locking, and IIRC not used in Win32 - though things like SRV can use it.