none
Physical Storport Miniport - Callback to user mode application or kernel driver RRS feed

  • Question

  • For a physical storport miniport driver, are either of the 2 following scenarios going to cause problems (e.g. execution problems or HCK violations)

    1. Exchanging callback function pointers between my miniport driver and a kernel-mode filter driver? (i.e. can my miniport driver use these callback pointers to call directly into the filter driver and vice versa)

    2. Miniport driver uses a callback pointer directly call a user-mode application's function.

    If this is acceptable, do I simply exchange these callback pointers with a passthrough command between the filter driver/application and my miniport driver? Or is there a Windows architected way to do this? (e.g. something like HwStorProcessServiceRequest for Storport virtual miniport).

    Wednesday, June 4, 2014 9:26 PM

Answers

  • You cannot call user space from a kernel mode driver period, at most you can do is an inverted call.  Nor can you for a clean miniport driver (i.e. in the spirit of the HCK) do this and have an external dependancy what so ever.   There are ways to do it, but why don't you say why you think you need this.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Wednesday, June 4, 2014 9:41 PM

All replies

  • You cannot call user space from a kernel mode driver period, at most you can do is an inverted call.  Nor can you for a clean miniport driver (i.e. in the spirit of the HCK) do this and have an external dependancy what so ever.   There are ways to do it, but why don't you say why you think you need this.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Wednesday, June 4, 2014 9:41 PM
  • Thank you for the quick response. I need to do some homework and read up on inverted calls.

    For the function calls initiated by the storport miniport driver, those calls would be made to notify the filter driver (or user app) of async events coming from the device - most likely error conditions. 

    As for function calls from the filter driver to the miniport driver, the idea is to avoid the overhead of making an IOCTL call through Storport - although I don't currently have measurements to quantify that overhead.

    I ran across an article that discusses allocating a shared context block between the kernel drivers. The articles suggests using that common space for common queues, spinlocks, function pointers, etc. It seems like that is a reasonable solution to my question. Do you have thoughts on that?

    http://www.osronline.com/article.cfm?id=177

    Thanks for you input.


    • Edited by tsfreeman Thursday, June 5, 2014 1:51 PM
    Thursday, June 5, 2014 1:50 PM
  • To fit into the Storport model, I would not use shared memory this violates the HCK goals.  Take a look at WMI for Storport, start with StorPortNotification, this designed to report asynchronous events such as errors.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Thursday, June 5, 2014 1:59 PM
  • Once again.... thanks for the information and the quick response.
    Thursday, June 5, 2014 2:01 PM