On 2012.06.18 20:31, Peter Stuge wrote: > What does GetLastError() return in the relevant cases after the > WinUsb functions return FALSE?
I'd expect "[22] The device does not recognize the command". > In any case, if transfers have been submitted and are on the flying > list, and if timeouts are working, then the transfers must at the > very least time out, even if WinUSB makes it impossible to determine > exactly why. In this case, a debug log from Liam should tell you. >> If you want to call it a bug, then call it a deliberate bug, > > It's a bug also if you implemented the behavior on purpose. It > doesn't match the libusb API in any case. As I said, if you insist on calling it a bug, you can call it a deliberate bug. Yet, a deliberate bug still belongs to the general bug category. > The topic is that transfers don't complete at all rather than the > error code. The topic is that someone unplugs a device and expects some specific unplug handling to occur, whether mentioned in the API or not, which we decided not to care about in Windows on the grounds that it'd be foolish to do so before we have a better view of the global hotplug handling that is going to be implemented soon(ish). Thus, unless there is an issue when the device remains plugged, I'm not planning to do a thing about it before global hotplug event handling is in. It just seems like a waste of resource. >> which is something you recently tried to get Uri to to test for you > > I asked Uri about what happens when drivers are replaced, which is > distinct from physical unplugging, even if the same thing happens in > both cases. (It makes sense for the same thing to happen.) I was referring to the following: On 2012.05.17 14:27, Peter Stuge wrote: > If a device becomes unavailable (which can happen without this patch > too of course) then the backend has to start failing transfers with > LIBUSB_ERROR_NO_DEVICE. Is this what currently happens? >> (whereas you could really have spent 30 seconds looking for libusb >> error codes returned by the Windows backend and easily found out >> the answer you were looking for), > > Static analysis is fine, but empirical testing is even better. Checking for all the occurrences of LIBUSB_ERROR_NO_DEVICE in the Windows backend, and which function calls they belong to, would have answered the question above without asking for someone to test it for you. >> >>> You are the first one to report it, but there have not been very many >> >>> reports of libusb use on Windows at all, so that doesn't mean much. >> >> >> >> Liam, I'm afraid you'll find that many people on these lists don't >> >> agree with these kind of subjective statements from Peter. >> > >> > I guess that Liam gets the point; we don't have much data, so we >> > can't say that this is a known problem. >> >> No. The point you have been trying to make, is that the Windows >> backend is subpar compared to the rest of libusb and also that >> extremely few people use it. > > Don't make things up. Do I have to conclude that your earlier statements with regards to the poor state of the Windows backend compared to the rest of libusb, on linux-usb as well as OpenOCD were made up as well? Or do they bear no relation whatsoever with what you have been trying to state here? But see below for the 2 possible interpretations of what you wrote, and how made up each of those may appear. > What I did write, and you've quoted it several times now, is that > there were few *reports*, which "doesn't mean much" because there > can be many users who do not have the same trouble as Liam but have > not let us know, because everything is working. Well, first of all, more than 2 years of mailing list archives do dispute the "not very many reports of libusb use on Windows", be it either for expected or problematic usage, which is really what I have a problem with here. Maybe it's because I'm the Windows backend maintainer, but this is not how I have seen things for the past few years at all. And you are also now somehow distorting "reports of libusb use" into "reports of bug", which of course changes the meaning of the earlier sentence altogether. Nice one. Still, what would you say is the most logical interpretation of your: "You are the first one to report it, but there have not been very many reports of libusb use on Windows at all, so that doesn't mean much"? 1. This is the first report we have for this issue, but not many people *use* libusb on Windows, so there's a good chance it's a major issue in the library. Or 2. This is the first report we have for this issue, but, since we don't receive many *issue* reports for Windows, when the expectation is that many people *use* it, there's a reasonable chance your report is wrong. Is it just me, or does one of these 2 interpretations look a bit more made up than the other? Regards, /Pete ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
