-
Notifications
You must be signed in to change notification settings - Fork 49
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
Rework IRP locking #38
Conversation
Signed-off-by: Tormod Volden <[email protected]>
Signed-off-by: Tormod Volden <[email protected]>
Signed-off-by: Tormod Volden <[email protected]>
The inconsistent indentation was giving compiler warnings. Signed-off-by: Tormod Volden <[email protected]>
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 <[email protected]>
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 <[email protected]>
Same includes for 32-bit as for 64-bit. Signed-off-by: Tormod Volden <[email protected]>
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 <[email protected]>
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 <[email protected]>
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. |
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