none
Best approach between user application and driver communication RRS feed

  • Question

  • I have done research on how user app and driver communicate and everyone prefers IOCtl to namedpipe

    I have tried to find a scenario where the driver would send data to user app without the user app executing zwreadfile . I really want whereby I can send data from the driver to user app but the user app must not call deviceiocontrol function it will just be in a loop waiting for the driver to write. This is my first scenario

    secondly with a namedpipe I have a function that is notified when a packet based on the filter I set is notified and this function has will write to the namedpipe using zwwritefile but many discourage using namedpies because they are undocumented

    so how do I deal with this which approach should I take

    anyone with solution on the first scenario


    • Edited by davescxp Monday, November 14, 2016 7:21 AM
    Monday, November 14, 2016 7:20 AM

Answers

  • Yes, named pipes are not documented for KM to UM and they do not behave the way you think they behave (IOW, not like Linux). for the first scenario, if you have your app in a loop waiting for the driver to write information, this is no different then sending an IOCTL and then waiting for its completion. Absolutely no difference.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, November 14, 2016 7:59 AM

All replies

  • Yes, named pipes are not documented for KM to UM and they do not behave the way you think they behave (IOW, not like Linux). for the first scenario, if you have your app in a loop waiting for the driver to write information, this is no different then sending an IOCTL and then waiting for its completion. Absolutely no difference.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, November 14, 2016 7:59 AM
  • ok

    so what do you really mean I have two thoughts below

    First thought

    Create a loop

    call deviceiocontrol to get message from driver .The deviceiocontrol will send an empty buffer and IOCtl_code Is get_packet and it will receive packet information

    ////////////////////////////////

    Second thought

    create a loop

    call deviceiocontrol to get message from driver .The deviceiocontrol will send an empty buffer and IOCtl_code is get_packet

    when packet is received by the callout of the driver the packet is immediately added to a que

    so when ever the user app request for packet the driver will send the first packet in que to the user application

    which thinking really works 


    • Edited by davescxp Monday, November 14, 2016 11:03 AM
    Monday, November 14, 2016 11:01 AM
  • You are still thinking in a Linux style.   Send a bunch of IOCTL's down to the driver using async I/O then wait for one to complete.  You may still need a buffer once in a while, but normally you will have a bunch of buffers waiting for packets.

    This is one of the problems I encounter all the time with firms that are used to Linux.  They use a synchronous I/O model, and expect it to work well when moving to Windows.   I had a client who demanded this model, and we got less than 100,000 operations per second from the device, once we went to async we passed 750,000 ops.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Monday, November 14, 2016 4:50 PM
  • I am not sure if am right. But in this scenario , is it OK to use event sharing between user app and kernel in this scenario? Everytime there is data available in driver side, the driver can set this event and thus notify the client so it can read the data.
    Friday, November 25, 2016 12:50 PM
  • Event sharing can be used, but there are problems with it.  First events only indicate signaled or non-signaled, so you need a second mechanism to handle the case of more than one item of data being available.   Second, a large portion of the overhead is crossing the user space to kernel space boundary, using an event then retrieving the data means two such crossings, where one is needed for the IOCTL's with async I/O.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Friday, November 25, 2016 1:03 PM
  • In both patterns the app is waiting on an event. Another benefit of the async ioctls pattern is that the logic is very simple. For the other pattern (wait on an event, then query) the app doesn't know how much data to query for and that can grow between event sets.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, November 25, 2016 6:47 PM
  • Well, that's clear..Thanks for the replies..
    Monday, November 28, 2016 5:01 AM