-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DMF_CONTEXT_GET and DMF_CONFIG_GET issue #42
Comments
Hello, Laengand, Something is wrong. It looks to me like you are passing the wrong DMFMODULE handle to DMF_CONTEXT_GET(). Please note that when a Child Module callback happens, the callback always receives the DMFMODULE of the Child Module, not the Parent Module. This is the same as how WDF works. For example, when a WDFTIMER callback happens, it receives the WDFTIMER of the timer object. So, the when a callback happens you need to use the following pattern:
I am assuming that perhaps you are not getting the Parent Module. It is invalid to do the following:
DMF_CONTEXT_GET() is always local and private to the Module. That is why it is declared only in the Module's .c. Please let me know if that is the cause of your problem. If not, I am happy to look at your code if you want to send me a function where this is happening. You can also look investigate the DMFMODULE by doing this in the debugger: !wdfkd.load There you can look at the Module handle data and see the name of the Module (ModuleInstanceName). |
Hi The video shows the Open function of Dmf_UsbDevice. which is called by its Create function. Stepping into DMF_CONTEXT_GET reveals that the HostController function is called. |
Hi, laengand, While looking, I would like to ask a question: Is there a reason you are creating If you do that, I am sure it will resolve your issue. For an example, please see Having said that, we are going to investigate the strange behavior your a seeing and get back to you. |
Hi I agree that it would make sense to let the I'll take a look at the toasterbus example. |
Hi, laengand,
The only changes I made were to how the include DMF is included. It is not clear to me yet exactly what is wrong about how you included but I will try to track that down. For now, I have attached the corrected files for you here. Note that you are not supposed to include This is how your includes should look (All Module should include files in this way)
Dmf_UsbDevice.c
(You can replace "Template" with "Library". I added them to the Template library for the test.) Please do a diff between your files and my files. It looks to me like when you include Dmf_UsbDevice.h inside of Dmf_HostController.h it causes the issue you are seeing because the compiler makes DMF_UsbDevice_Create() inline. We will try to resolve the issue by making macros DMF_CONTEXT_GET() and DMF_CONFIG_GET() as static to prevent this possibility. |
Hi, laendand, Please see the files in this .zip file (and see the my previous comment): This is the correct way to add Modules to a Module Library. In the Client driver you are only supposed to include the Module Library's Module Include file. In my case, it is That is the only place that In the Client driver you only need to include the following: #include <DmfModules.Template.h> In the Modules, you only should include the following: #include "DmfModule.h" #include "Dmf_HostController.tmh" (Note: Do not include Trace.h.) That will fix your issue in the correct way. Having said that, we will at a later time, update the macros One more thing: Note that Modules are agnositic about their parents. It is generally not correct that you DMF_UsbDevice's Parent is DMF_HostController. It seems like you are doing that. Let me know if you have questions. |
Hi, laengand, I have spent a lot of time looking at this issue and I am unable to repro it exactly. One thing I want to tell you is: You are not supposed to include the Module's .h files directly in your driver. The Module's .h file is only supposed to be included in a single place: The Module Library's Include file. Then, your driver is only supposed to include the Module Library's Include file. So, in my example, I added your Module to Template Library. Then, in the Template's Include file I added your Module include files. Then, in your driver you are only supposed to include Modules.Template.h. Then, I link to Template Library. Note that you are not supposed to add Module directly to your driver. You add them to the Library so that all the dependencies exist (both compile and link) in the Library. Then, you link your driver to that Library. When I do not include the files as I state above, I see some similar behavior (but not exacty) to what you describe. I also added "static" as you did and I did not see a difference. |
Hi, laengand, No matter what I do, I am unable to repro this issue. It is my belief that you are including the Modules directly into your driver which is not correct. I tried doing that also to repro your issue, but I was still unable to do so. I am going to close this issue with out a fix because I don't want to make a change for the wrong reason. If you can work with me to help me repro the issue (even if I can see it remotely), I am happy to do so. To be clear, Modules should be added to a Module Library. Then, the Client driver includes that Library's path in the #include directory and that Module's Library in the Link directory. The include files of every Module should be the same in each Library. Thank your for brining this issue to our attention. Please contact us again or open this issue again if you wish pursue it further. |
Hi again |
Hi samtertzakian
Doing this removed the need for using the static DMF_CONTEXT_GET and DMF_CONFIG_GET Thank you for your assistance |
Hi laendand, It is great news that you were able to make things work. Thank you for taking the time to reorganize your code. The reason that Client drivers should link to Libraries is that each Module's dependencies (on other Modules) is already encoded in the Library. Regardless of how the a Module uses other Modules (or other Modules use it), when you link to a Module in a Library, you automatically get all its dependencies (even if they change in the future). The include files assume programmers will follow that model. The Include files are designed to hide DMF APIs used only by Modules from Client drivers. So, it is best to include the DMF include files just like the samples do. 100% of our drivers do the same. I am planning on adding a section in the documentation to address this issue (Client drivers to should link to Libraries not Modules) and other similar issues. Thank you again for reporting this issue. |
So I have written and declared 2 modules: Dmf_HostController and Dmf_UsbDevice
Each Module is based on the Dmf_Template.h/c
I noticed that whenever Dmf_UsbDevice called its DMF_CONTEXT_GET, it would call the DMF_CONTEXT_GET of the Dmf_HostController instead. If I remove the Dmf_HostController from the project the Dmf_UsbDevice calls the correct DMF_CONTEXT_GET.
I looked through DmfModule.h and found DMF_MODULE_DECLARE_CONTEXT. If I append the static keyword like this:
Then Dmf_UsbDevice calls the correct DMF_CONTEXT_GET.
The same issue arises when calling DMF_CONFIG_GET.
So it seems the compiler inserts the wrong function when calling DMF_CONTEXT_GET and DMF_CONFIG_GET
Kind regards
The text was updated successfully, but these errors were encountered: