Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Bi Directional Bus driver Interfaces in kmdf

amaramar Member Posts: 1

I am working on project which is having bus driver, sits over hardware and child driver dynamically enumerated
I want bi directional communication between child & bus driver and realized that either it could be

-->IOCTL based (2 Ioctls - pending ioctl for reading from Child to bus driver & ioctl for sending data to Bus driver from child driver)
--> bidirectional interface - https://www.osr.com/nt-insider/2014-issue2/using-bus-interfaces-driver-driver-communication/

Ioctl based interface automatically take care of D0 exit cases bcz interface automatically
get deactivated + we can always configure queues in our own way but demerit is that at least one ioctl is always pended
and need to be completed/cancelled for graceful exit.

--> My question is

:In Stack tear condition which start from top to bottom - if child driver is going to unload or unloaded and bus driver sent a call to child driver then it would cause blue screen -- how to handle this situation??

In power down cases if child driver already gone to D0 exit and then simultaneously call comes from bus driver
what ll happen and how to handle this ??

what do you suggest --which interface is better - Ioctl or Bus driver

Thanks

Comments

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,261

    With the bus interface you're really just exchanging function pointers between the two modules. So, yes, you need a mechanism for coordinating the teardown of the connection between the two modules. I like using Run-Down Protection for this sort of thing, but that's just one way to solve the problem and it may or may not be appropriate for your design.

    There's nothing inherently better about IOCTLs vs a Bus Interface. Bus Interfaces are an efficient way for one driver to make synchronous calls into another driver. Synchronous IOCTLs are also pretty efficient, but are always going to have more overhead than just making a subroutine call.

    If you try to do something asynchronous through a Bus Interface then you end up creating something that looks an awful lot like the WDFREQUEST interface, in which case you're better off using IOCTLs.

    To give some examples from OSR history of when we chose one versus another:

    1. We wrote a disk filter driver A that needed to ask another driver B for some information on each and every disk I/O. We used a bus interface to reduce the overhead of the calls from A to B
    2. We wrote a bus driver for a custom protocol bus that could tunnel I2C. The children had to talk to the bus driver to read/write their devices. The operations were always asynchronous, so we used IOCTLs

    -scott
    OSR

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA