When a KMDF driver uses the FsContext pointer in the WDM FILE_OBJECT to
store the relationship between WDM FILE_OBJECT and WDFFILEOBJECT is the
?value? placed in the FsContext field reliably meaningful to a WDM
PreProcess routine?
Take for instance the case where a WDM PreProcess routine would like some
information from the context associated with a WDFFILEOBJECT.? Is it
possible through supported mechanisms to traverse from the PFILE_OBJECT in
the current stack location to the WDFFILEOBJECT without resorting to hackery
or inefficiency?
The only scheme I can see at present would be to tell KMDF to *not* use the
FsContext slot and to manually stash the WDFFILEOBJECT ?context? pointer (or
handle, or whatever) in the FsContext field.? That way a WDM pre-process
routine can be assured of the interpretation of the value.?? The terrible
down-side is that KMDF must then resort to some internal indexing or some
such to map a PFILE_OBJECT to a WDFFILEOBJECT since it cannot simply stuff
its own pointer in there.
It would be really quite useful if the value placed into the FsContext field
was something that could be fed back to KMDF to retrieve the
WDFFILEOBJECT.?? Is it by any chance a ?context? pointer?? It sure is not a
WDFHANDLE but instead appears to be the WDFOBJECT (FxFileObject).? AFAIK,
this value is entirely useless to a KMDF driver.
If the best scheme is to store the context address in the FsContext field
and use WdfObjectContextGetObject() to ‘get back’ to the WDFFILEOBJECT, what
(and in what paths) is the penalty for managing or searching the ‘index’ to
map PFILE_OBJECT to WDFFILEOBJECT?
Regards,
Dave Cattley