Lazy CreateFile with WinUSB backend #1181
Conversation
0872ad3 to
3b373df
Compare
|
I'm satisfied with current implemention. It's get a little tricky but reasonable. From my perspective it would be nice to get some feedback from someone with better understanding of libusb internals. I've done some testing with composite and non-composite devices but my plan is to repeat them in more formalized manner before dropping WIP status. However I will be able to do that in ~2 weeks and I wanted to share current status. There is dependency on PR #965 which waiting for some formatting fixes. If necessary I'm willing to apply them in this PR |
|
I finally managed to properly test these changes - things are working correctly, see test report linked in PR description. |
|
It is great that you have included a test report. I would be reassured if we had some more review comments and testing from others as well though. @RyanMetcalfeNovanta what do you think about this PR? |
3b373df to
ccac965
Compare
|
@tormodvolden @mcuee I've rebased this branch on top of changes in #965 and performed testing again - works as expected, also in real use case where I found this issue in first place |
ccac965 to
aa60876
Compare
177bebf to
fe8cae8
Compare
|
This is not a test for the purpose of this PR (using two applications to access different interfaces of the same device), but rather to show some behavior differences of this PR with git master. Test device: Raspberry Pi Pico W with CicrcuitPython FW. I have used WinUSB driver to replace the Mass Storage driver (Interface 2), the CDC-ACM driver (Interface 0/1, with IAD) and the USB Audion Driver (Interface 4/5, no IAD). Interface 3 is using USB HID driver (USB HID Keyboard). Take note Claiming Interface 5 will fail as it is not using IAD -- therefore PR #965 will not help. |
|
Please take a look at my test result and see if the differences are expected. Thanks. |
fe8cae8 to
26b5740
Compare
|
@mcuee Branch rebased with changes as requested by @tormodvolden applied. I still need to do some testing but I would like to at least let you proceed with code review. I don't see any dangerous differences in outputs you provided. Probably verbosity of logs is a bit to high (will reduce them to debug). Could you re-run xusb with rebased branch? I assume that lack of "Reading OS string descriptor" is caused by not-including something that was added recently. I don't quite understand what Max LUN is and why it is different (it should be the same?) |
26b5740 to
d67cf68
Compare
|
Great. Now I do not see differences between git master and this PR. Ignore the MAX LUN number as it seems to be random -- it seems to me the USB Mass Storage in this Circuit Python FW is not compliant and the number is random. |
Here you go https://gist.github.com/Novakov/894862d4e9d8316ef5bd976cc85c2ea1 but I'm afraid that will be of little use to you without corresponding custom USB device. |
Thanks. It may still be useful if I take out the device specific codes. I need to carry out minor changes in order to build under MSYS2 mingw64. The following zip file includes the modified code and binary. |
|
Any other changes required from your side? I understand that you want more reviewers who are familiar with Windows as well. |
|
Yes, it is not in my capacity to approve this. At least not yet. |
|
Hopefully more people can review this one. @martinling and @sonatique |
|
@Novakov : Thank you for this PR. I read your proposed changes and I have a question: As far as I understand, with current master code, it is possible to open a device and start doing control transfers before claiming any interface. I think that this is in line with how USB is designed: you only need to claim an interface for accessing "user" endpoint (endpoint number > 0). This means that in practice, an application can do control transfers for as long as it want without claiming interface, and it is even possible for multiple application instances to do so concurrently (as long as the driver supports it, which is the case for libusbK): applications would open the same device and get an handle for issuing control transfers. It is only when one application wants to use another endpoint that it has to claim an interface. From now on, other application would not be able to claim the same interface, hence will be prevented from using the same non zero endpoints. If I read you commit correctly, 'winusbx_open' doesn't really do anything any longer, i.e. there is no file open for My question is: wouldn't this prevent the behavior I described above? Would an application that use control_transfers before I would tend to answer "yes" given the file_handle in current master code are only used or interface_handle, but I wanted to make sure. Thank you in advance. |
|
@sonatique Application that issues control transfer before claiming interface will work as libusb will automatically claim interface (which will result in opening device file if necessary) and release it after control transfer is completed (and possible close device file). This behavior is already present in master branch under auto-claim name. This PR "only" delays opening device file handle until absolutely necessary. |
OK, yes, thank you, found the code. So, the PR looks good to me, thank you. |
|
This PR seems to be good to go. Any changes needed from your side? |
|
Github says I have one change requested, but I cannot find it... So we have:
I think I must review it more in detail to give my own approval. But a multitude of documented tests would help also. |
|
Looks like we have to postpone this after 1.0.27 release. Still, please help to rebase your PR -- I'd like to test this PR again. Thanks. |
Windows manages each sub-device of composite device as separate device - each one requires separate call to CreateFile to obtain dev_handle. Opening all sub-devices eagerly prevents other applications for accessing any sub-device even if application that opened the device is not using them. This commit modifies WinUSB backend to call CreateFile lazily, so device handle is opened when necessary (by claiming the interface) and release as soon as possible (by releasing the interface). Implementation details: * winusbx_open becomes essentially no-operation * winusbx_claim_interface ensures that device handle is opened * interface used to initialize WinUSB handle has associated counter of claimed interfaces * claiming and releasing interfaces modifies ref-counter accordingly * when counter reaches zero on releasing interface, device handle is closed Signed-off-by: Maciej Nowak <[email protected]>
d67cf68 to
43d16cd
Compare
|
@mcuee Branch rebased on top of master, no conflicts reported. I did not run my usual test suite after rebasing. It is ~day of work to go through all test cases, so I will run them once I get some confirmation that this PR will be merged soon(ish) |
Thanks a lot.
That is okay. As of now, this PR will need to be postponed due to lack of resources. The idea is to fix Regression Issue #1386 and then release 1.0.27. Then this PR will hopefully get more reviews and be merged eventually. |
|
First test shows that this PR is fine with an USB Composite Device (but git HEAD is also okay), one WinUSB interface and the other HID interface. |
|
So, is there any chance for this PR to be merged someday? |
We hope to bring in reviewers who are more familiar with libusb project especially the Windows backend to help review and merge Windows related PRs. |
|
Please take a look at this PR when you got the time. Thanks. |
This is work-in-progress, I'm opening PR to get initial feedback/review and possibly be tested by others.
Fixes #1177 and includes changes from #965.
Summary of changes:
winusbx_openessentially no-opwinusbx_claim_interfaceis called it ensures that device handle is valid, if not -CreateFileis called.winusbx_release_interfaceuses refcounting to release WinUSB device and device handle.I did not test how it behaves with libusb-filter (never used that, so some catching up to do first).With composite device containing several WinUSB devices (some of them grouped in IAD) libusb behaves correctly -CreateFileis delayed until claiming interfaces and handle is closed as soon as last associated interface is released.Test report https://gist.github.com/Novakov/4b2d4094825b83ef58b23060224660f8
printfs are left on purpose and will be removed before finalizing - I'm dropping recompiledlibusb.dllwhere I can (OpenOCD and Orbuculum mostly) to check if devices are opened/closed as supposed to, having debug printfs available makes it easier.