Rework IRP locking #38
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
The inconsistent indentation was giving compiler warnings. Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
The preprocessor introduces a space between L and the string: L "abc" and GCC will fail to recognize this as one token. Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Many things have improved in MinGW over the years and less special-casing is needed. Due to many DDK header files referring to each other without the ddk/ path prefix, we must tell make where to find the include/ddk folder, e.g. (Ubuntu 20.04): make host_prefix=i686-w64-mingw32 ddk=/usr/i686-w64-mingw32 driver or make host_prefix=x86_64-w64-mingw32 ddk=/usr/x86_64-w64-mingw32 driver
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Same includes for 32-bit as for 64-bit. Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
This follows Scenario 7 from https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/different-ways-of-handling-irps-cheat-sheet Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Also add a debug print for lower driver failure. This corresponds to Scenario 2 from https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/different-ways-of-handling-irps-cheat-sheet but with the IO completion done by the calling code. Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
Please help to look at this PR when you got the time. Thanks. |
|
Really impressive patch @tormodvolden. Quick question: most of the patches are cosmetic, but the last 2 can have deeper impact. Thanks, /pedro |
|
Ah, OK i answered my own question. The failing test case was here: libusb/libusb#1255 Yes, my original fix was just not good enough :-( Thanks again @tormodvolden for fixing this. Approved. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is on top of my PR #36
Note this has only been minimally tested with xusb.exe so far.
driver: Rework cancel and timeout handling in call_usbd_ex
This is based on the "text book" (the MS documentation referenced in the commit message)
The original code is using the same event for 2 different purposes, which I think is wrong.
driver: Allow synchronous return from lower driver in get_current_frame
Also just based on code review and MS documentation.
I am curious whether this (especially the call_usbd_ex patch) can help for issue libusb/libusb#1255