hot unplug on windows, only 3 IN transfers complete

[Liam Staskawicz]

Hi,

I'm using libusb 1.0.9 on windows7 (building a Qt app with msvc2010), and things are largely working just as expected - thanks for a lovely library with winusb support!

My device is vendor specific, with one IN and out OUT bulk endpoint, each 64 bytes. When my device is opened, I submit 16 IN transfers to make sure I can keep the system busy servicing usb IN traffic. Sending and receiving using the asynchronous API is no problem, however, when my device is unplugged, I would ideally like to cancel all outstanding transfers, wait for them to complete, and then close the device. This works as intended on OS X, but on Windows I only ever see 3 transfers complete so I don't have a good way to know whether all outstanding transfers are complete. If I limit the outstanding requests to 3, then I can detect the case in which all requests have completed, and close the device successfully.

A couple questions:

• is this an appropriate way to manage the process of closing my device?
• does this issue sound familiar to anybody?
• any suggested workarounds?

Thanks in advance,

Liam

------------------------------------------------------------------------------
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/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

CC libusbx. Maybe Pete and others can give you better answers there.

On Tue, Jun 5, 2012 at 11:09 PM, Liam Staskawicz <[hidden email]> wrote:

> Hi,
>
> I'm using libusb 1.0.9 on windows7 (building a Qt app with msvc2010), and
> things are largely working just as expected - thanks for a lovely library
> with winusb support!
>
> My device is vendor specific, with one IN and out OUT bulk endpoint, each 64
> bytes. When my device is opened, I submit 16 IN transfers to make sure I can
> keep the system busy servicing usb IN traffic. Sending and receiving using
> the asynchronous API is no problem, however, when my device is unplugged, I
> would ideally like to cancel all outstanding transfers, wait for them to
> complete, and then close the device. This works as intended on OS X, but on
> Windows I only ever see 3 transfers complete so I don't have a good way to
> know whether all outstanding transfers are complete. If I limit the
> outstanding requests to 3, then I can detect the case in which all requests
> have completed, and close the device successfully.
>
> A couple questions:
>
> is this an appropriate way to manage the process of closing my device?
> does this issue sound familiar to anybody?
> any suggested workarounds?
>

libusbx-2.0 will add hotplug support and that should help.
http://sourceforge.net/apps/trac/libusbx/roadmap

More about libusbx:
http://www.libusbx.org/

libusbx mailing list subscription:
https://lists.sourceforge.net/lists/listinfo/libusbx-devel


--
Xiaofan

------------------------------------------------------------------------------
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/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Peter Stuge]

Hi Liam,

Liam Staskawicz wrote:
> when my device is unplugged, I would ideally like to cancel all
> outstanding transfers, wait for them to complete, and then close
> the device.

Nod.


> This works as intended on OS X, but on Windows I only ever see 3
> transfers complete

If the later 13 were successfully submitted then that is a bug in the
Windows backend.


> - is this an appropriate way to manage the process of closing my device?

Yes, it is. In particular libusb_close() doesn't cancel running or
pending transfers. There has been a bit of discussion recently about
being able to mass-cancel anything running or pending, and about
libusb_close() doing so automatically. I think this is an important
addition to the API.


> - does this issue sound familiar to anybody?

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.


> - any suggested workarounds?

No workaround. :\ If the Windows backend accepts a transfer then it
must also complete, regardless of whether the device is there or not.

Could you help look into the problem? I hope Pete will also look into
it in the context of the libusbx project (he forked libusb) and if a
bug fix comes out of that it will of course also be included in
libusb, but I would actually recommend to dive into the code and try
to discover the problem on your own. (The libusb and libusbx code is
the same.)


Kind regards

//Peter

------------------------------------------------------------------------------
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/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Pete Batard-2]

On 2012.06.18 11:50, Peter Stuge wrote:
>> This works as intended on OS X, but on Windows I only ever see 3
>> transfers complete
>
> If the later 13 were successfully submitted then that is a bug in the
> Windows backend.

Or rather, this is because OS-X has some pre-emptive implementation of
hotplug, to be able to do so, which is a feature that libusb does not
yet provide as a whole. Peter, please take a look at the Darwin code.

The actual bug is that libusb still does not globally support hotplug,
as demonstrated with yet another issue where someone has a problem with
an hotplug related scenario. This is getting old...

>> - is this an appropriate way to manage the process of closing my device?
>
> Yes, it is.

Or rather, it would be, if we had implemented global hotplug support,
which we should (and could) have done years ago.

> I think this is an important addition to the API.

Indeed, hotplug support is.

>> - does this issue sound familiar to anybody?
>
> 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. This is actually
one of the the reason the libusbx fork exists.

>> - any suggested workarounds?
>
> No workaround. :\ If the Windows backend accepts a transfer then it
> must also complete, regardless of whether the device is there or not.

Of course, by definition, doing so does requires some form of hotplug,
either private or global...

> I hope Pete will also look into it in the context of the libusbx project

As the saying goes, you don't put the cart before the horse.

I think most people will agree that it makes little sense for each
backend to do their own private implementation of hotplug, only to see
it redone with the planned global hotplug implementation. And this is
the reason why the Windows backend is not doing anything special there.

Maybe the OS-X backend didn't think global hotplug support would be
implemented any time soon (which they were probably right about at the
time), and thus they compensated for it by adding their own local
implementation. But at least as far as libusbx is concerned, we do have
plans to start looking into adding global hotplug support soon(ish), so
it would seem unwise, in terms of effort, to duplicate that effort in a
backend

Liam, I know this is probably not the answer you are looking for, but
for now, I'd encourage you to follow what's occurring with the libusbx
project, especially with regards to the planned development branch, as
this is the place where you should first see support for device
disconnection being added. But until that is done, you avoid relying on
libusb(x) for any scenario that involves hot plugging of a device.

/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/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Peter Stuge]

Hotplug isn't there yet, and Liam's problem is because the Windows
backend doesn't currently implement what the libusb-1.0 API currently
offers. Without hotplug. This is a bug in the Windows backend.


> >> - is this an appropriate way to manage the process of closing my device?
> >
> > Yes, it is.
>
> Or rather, it would be, if we had implemented global hotplug support,

It's the appropriate way to use the libusb-1.0 API both right now and
once a hotplug feature is available.


> > 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.


> avoid relying on libusb(x) for any scenario that involves hot
> plugging of a device.

libusb-1.0 supports hot-unplug since 2008, but the Windows backend
has a bug in implementing that.


Since Pete doesn't seem interested to fix this I'll repeat the
suggestion for Liam to have a look into the code. Or at the very
least please create a ticket against the Windows backend. Patches
for libusb to fix this right now are certainly welcome!


//Peter

------------------------------------------------------------------------------
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/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Johannes Stezenbach]

On Mon, Jun 18, 2012 at 02:39:45PM +0100, Pete Batard wrote:

> On 2012.06.18 11:50, Peter Stuge wrote:
> >Liam Staskawicz wrote:
> >> This works as intended on OS X, but on Windows I only ever see 3
> >> transfers complete
> >
> > If the later 13 were successfully submitted then that is a bug in the
> > Windows backend.
>
> Or rather, this is because OS-X has some pre-emptive implementation of
> hotplug, to be able to do so, which is a feature that libusb does not
> yet provide as a whole. Peter, please take a look at the Darwin code.
>
> The actual bug is that libusb still does not globally support hotplug,
> as demonstrated with yet another issue where someone has a problem with
> an hotplug related scenario. This is getting old...

Doesn't Windows (WinUSB to be precise) return an error code
indicating the device was unplugged for the submitted transfers?
If Windows only returns "unlugged" status for one transfer
and forgets the other ones, can't you just fix this up in the
libusb Windows backend?


Johannes

------------------------------------------------------------------------------
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/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Pete Batard-2]

On 2012.06.18 15:37, Peter Stuge wrote:
> Hotplug isn't there yet, and Liam's problem is because the Windows
> backend doesn't currently implement what the libusb-1.0 API currently
> offers. Without hotplug. This is a bug in the Windows backend.

After 2 similar issues, you still don't get it, so let me try to explain
that to you in black and white:

1. Implementing this will require some form of hotplug handling in the
Windows backend similar to what we would do for global hotplug handling
(i.e. separate event thread and the whole shebang). There's no other way
around it.

2. Some form of hotplug implementation is going to be added once we
apply the global hotplug patch, which we have more or less available. We
have known for the past 2 years that this global hotplug implementation
is going to happen.

3. Therefore, since we are *naturally* going to get a hotplug
implementation in the Windows backend, which we can subsequently rely on
to implement anything that pertains to device removal, it doesn't make a
shred of sense to pre-empt this planned effort and go through a limited
implementation, especially any such effort may have to be reviewed and
altered once we are through with global hotplug. You may also want to
consider that there could exist a possibility to factorize some of the
removal related features, instead of having each backend implement its
own. Wouldn't it make more sense then if, instead of having people doing
their own custom backend implementation, they instead invested their
time trying to factorize that handling in core?

Thus, the API can say whatever it wants with regards to what occurs on
device removal, it doesn't make sense for anyone to go out of their way
implementing it in a new backend when they know a global hotplug effort
is underway. And that is the approach the Windows backend implementation
has taken. If you want to call it a bug, then call it a deliberate bug,
because, with the API requirement to send a specific error code on
device removal, which is something you recently tried to get Uri to to
test for you (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), we just said "we'll do that once we
have global hotplug".

There is such thing as doing things in a specific order to minimise the
resource costs, especially when resources are far from being unlimited.
Look it up. You may learn a thing or two about project management...

 >>> 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, as corroborated from many
other posts from yours in libusb-devel and elsewhere, is that the
Windows backend is subpar compared to the rest of libusb and also that
extremely few people use it. Assuming that you have spent the last 2
years monitoring libusb-devel, I find this quite the disingenuous
statement to make, unless of course you can list some evidence to back
it up, which I have diligently been asking for each time you tried to
present your very subjective appraisal as an undeniable fact.

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/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Peter Stuge]

Pete Batard wrote:
> > Hotplug isn't there yet, and Liam's problem is because the Windows
> > backend doesn't currently implement what the libusb-1.0 API currently
> > offers. Without hotplug. This is a bug in the Windows backend.
>
> Implementing this will require some form of hotplug handling in the
> Windows backend similar to what we would do for global hotplug handling
> (i.e. separate event thread and the whole shebang). There's no other
> way around it.

What does GetLastError() return in the relevant cases after the
WinUsb functions return FALSE? The documentation is sparse.

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.


> 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.


> because, with the API requirement to send a specific error code on
> device removal, we just said "we'll do that once we have global hotplug".

The topic is that transfers don't complete at all rather than the
error code. I think it could be acceptable, though weak, for early
code such as this to have transfers time out if the device went away.
The situation however seems to be that they do not complete at all,
which is nothing other than a bug if indeed the case.


> 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.)


> (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.

>  >>> 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.

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.


//Peter

------------------------------------------------------------------------------
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/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Peter Stuge]

Johannes Stezenbach wrote:
> Doesn't Windows (WinUSB to be precise) return an error code
> indicating the device was unplugged for the submitted transfers?

Can you provide a debug log? I assume you check for submit errors,
and I'm interested in seeing what happens to those later 13.


Thanks!

//Peter

------------------------------------------------------------------------------
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/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Pete Batard-2]

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/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Peter Stuge]

Pete Batard 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".

Do you know all possible reasons are for that error code?


> > 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,

Think about it from the libusb API perspective rather than from the
Windows API perspective; someone unplugs a device and expects libusb
not to silently drop transfers. Even if Windows code doesn't yet
support hot unplug, like the rest of libusb for a long time, at least
transfers must not disappear.


> Thus, unless there is an issue when the device remains plugged, I'm
> not planning to do a thing about it

That's up to you of course. Thanks for clarifying!

> >> 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?

Right, "device" refers to the logical device representation that
libusb gets from Windows, not the physical thing.

Of course I can work only on code without communicating at all, but
for a new contributor I think pointers in interesting directions can
be valuable for getting the problem solved, and they also help to
show that there is interest in the problem.


> 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?

You're really overreacting to me clarifying for a user that the
observed behavior is a (deliberate) bug.


> > 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",
> either for expected or problematic usage,

Did you count? How many orders of magnitude off is ten-twenty then?
Fifty reports would still be "not very many", at least compared to
the hundreds of thousands SF number.


> 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.

Your sentence is confusing, but I think I understand it. "not very
many reports of libusb use" does not refer to reports of bugs, but
refers to reports of use, since I wrote "use."


> 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"?

I actually think it is fairly clear as-is, but..


> 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.

This is almost right, but you misinterpret the very part you emphasize.

I wrote nothing about how many people use libusb on Windows. We can't
know that. We can only know what we learn from actual feedback, and
not many people have said that they use libusb on Windows.

It could be hundreds of thousands, but it could also be ten-twenty.


Maybe you'll agree that libusb and libusbx Windows support is still
experimental though?


//Peter

------------------------------------------------------------------------------
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/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Orin Eman]

On Mon, Jun 18, 2012 at 4:07 PM, Peter Stuge <[hidden email]> wrote:

Pete Batard 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".

Do you know all possible reasons are for that error code?

FWIW, WinUsb_ReadPipe() will return 22 immediately if the device is disconnected, BUT a pending overlapped WinUsb_ReadPipe() may* complete with error 31 - ERROR_GEN_FAILURE if the device is disconnected.

windows_usb.c incorrectly thinks ERROR_GEN_FAILURE is a stall which should be an impossible occurrence if AUTO_CLEAR_STALL is set

Both the 22 and 31 return must be handled correctly as they can occur before any plug and play event is received.  It does seem that it's impossible to tell the difference between a device being disconnected and a stall if AUTO_CLEAR_STALL isn't set.

*I say may as I have only tested with one device.

Orin.

------------------------------------------------------------------------------
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/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Peter Stuge]

Orin Eman wrote:
> > > > What does GetLastError() return in the relevant cases after the
> > > > WinUsb functions return FALSE?
>
> FWIW, WinUsb_ReadPipe() will return 22 immediately if the device is
> disconnected, BUT a pending overlapped WinUsb_ReadPipe() may* complete
> with error 31 - ERROR_GEN_FAILURE if the device is disconnected.

Ok - but maybe we can work with that.


> windows_usb.c incorrectly thinks ERROR_GEN_FAILURE is a stall which
> should be an impossible occurrence if AUTO_CLEAR_STALL is set
>
> Both the 22 and 31 return must be handled correctly as they can occur
> before any plug and play event is received.

Right, thanks for expressing this very clearly. It's the point I
tried to make as well.


> It does seem that it's impossible to tell the difference between a
> device being disconnected and a stall if AUTO_CLEAR_STALL isn't set.

Is there a reason why we would ever not want to set AUTO_CLEAR_STALL?

It's done unconditionally now, which seems to be the right way to go
so that the 31 error happens for one less reason.


//Peter

------------------------------------------------------------------------------
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/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Peter Stuge]

Peter Stuge wrote:
> Is there a reason why we would ever not want to set AUTO_CLEAR_STALL?
>
> It's done unconditionally now, which seems to be the right way to go
> so that the 31 error happens for one less reason.

On the other hand, do other backends automatically clear stalls? If
no then Windows also shouldn't. If that means that transfers will
complete with LIBUSB_ERROR_IO instead of LIBUSB_ERROR_NO_DEVICE
then I think that's OK. It's impossible to report what Windows
doesn't tell us.


//Peter

------------------------------------------------------------------------------
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/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Pete Batard-2]

On 2012.06.19 00:07, Peter Stuge wrote:
> Do you know all possible reasons are for that error code?

Do I know the content of MSDN by heart? Do I believe that the WinUSB DLL
designers have documented all the possible reasons under which this
error code to be returned? Do I even believe that the error code I
mentioned is the only one that can be reported, even though I didn't run
a proper test? Also, do you have any other questions like this one?

>>> 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,
>
> Think about it from the libusb API perspective rather than from the
> Windows API perspective;

No. For once, think about what you are asking *others* to do before
stopping at what *you* want, and how the library should get closer to
*your* vision. If needed to be reminded, this is a collaborative effort,
and you're only one the participants.

I'll tell you frankly, that has to be your main point of failure as a
project maintainer, which is hugely surprising, as I would really expect
you to know better from direct experience in various projects. Somehow,
you seem to expect others to be at your every command, be it for patch
reviews (expecting for ACKs or others to lead reviews and whatnot, as
well as complaining that they don't), expecting time to be spent post
haste for every single thing you decide to tag as a "bug" (as per the
present and other issues), reworking an implementation that works fine
for our usage, but that you don't like ("Hey, I spent a few hours
conducting *limited* tests in wine - Therefore, I really think someone
should scratch the many more hours they spent on the exact same effort,
where they came with a completely different alternative, and just spent
the next few days following *my* guidelines"), compensating for compiler
limitations ("MSVC doesn't have named initializers? Someone should work
on implementing that!"), preventing the inclusion of samples unless
broken down as per your ideal vision, and so on...

And I could add that the irony is, when you do decide to take action
yourself, such as for timestamped log or reworking autotools files,
other people's input suddenly need not apply.

So, if you wanna talk about perspective, then let me try to extend your
perspective a little bit: the API is really only one part of it. And
it's far from being the one ring to rule them all. There is such thing
as trying to balance API requirements with resources, as well as user
requests...

>> Thus, unless there is an issue when the device remains plugged, I'm
>> not planning to do a thing about it
>
> That's up to you of course. Thanks for clarifying!

I think I have been pretty clear about this for quite some time.
Thus, I can only hope that it will *remain* clear then...

>> 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?
>
> Right, "device" refers to the logical device representation that
> libusb gets from Windows, not the physical thing.
>
> Of course I can work only on code without communicating at all, but
> for a new contributor I think pointers in interesting directions can
> be valuable for getting the problem solved, and they also help to
> show that there is interest in the problem.

BZZZT!

You specifically asked somebody *else* to answer a question *you* could
easily answer yourself. If you really wanted to help Uri, instead of
sending him on an avoidable quest, you would have checked the code to
answer that question, and alerted him to the fact that
LIBUSB_ERROR_NO_DEVICE may not be returned in case of hotplug, in the
remote case he could ever need that information. I kind of felt bad not
replying to that mail actually, to tell him so, but I also expected he'd
have better things to do than invest time on that one.

Considering your history, I think it is fairly safe to state that this
was yet another attempt at trying to get others point to elements that
you could then label as bugs in the Windows backend, which is something
I can't fail to notive you've been going on about for some time now. The
e-mails you sent over these last few months with regards to the Windows
backend are almost comical in the probability of seeing you utter
another one of your "This is a bug" statement at the earliest
possibility, regardless of whether any proper analysis has been conducted.

> You're really overreacting to me clarifying for a user that the
> observed behavior is a (deliberate) bug.

I'm reacting to what I see, which is the e-mails you've been sending to
various mailing lists of late. And they're looking awfully biased, but
short of evidence to back up that bias.

Also I am not reacting to your statement that this is a bug (since I've
gotten very used to your utterance of these words as pointed out above).
I'm reacting to your trying to pass your obvious *opinion* that the
Windows backend should not be trusted for lack of usage and that issues
should be expected there, as an undeniable fact that users should be
alerted to.

>>> 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",
>> either for expected or problematic usage,
>
> Did you count? How many orders of magnitude off is ten-twenty then?
> Fifty reports would still be "not very many", at least compared to
> the hundreds of thousands SF number.

Hey, didn't you use to state, when it was convenient to you as an excuse
*not* to produce a libusb release, that hundred of thousands of SF
downloads didn't matter that much, and that those users should use git
or distro packages (which, by the way, Windows also has had for some
time through cygwin...).

How about comparing reports with reports, since "not many reports of
libusb use on Windows" should logically be "in comparison with reports
of libusb use on Linux"? Of course, if we do that, then we all know that
your statement becomes complete bullshit, since we're not getting that
many more reports of use for Linus either.

Now if you want to go through an estimate of libusb/Windows use, through
analysis of figures, rather than try to compare SF downloads with
mailing list reports, have a look further down.

>> 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.
>
> Your sentence is confusing, but I think I understand it. "not very
> many reports of libusb use" does not refer to reports of bugs, but
> refers to reports of use, since I wrote "use."

Which is exactly how I interpreted it. I'm talking about reports of
libusb usage, and your implicit dimissal of libusb usage being that high
on Windows (with high enough seemingly being entirely up to you to define).

>> 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"?
>
> I actually think it is fairly clear as-is, but..
>
>> 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.
>
> This is almost right, but you misinterpret the very part you emphasize.

Then pray how is one supposed to interpret this following statement of
yours, that attempted to clarify the above:

 > 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.

How is "there can be many users who do not have the same issue and for
which everything is working" compatible with your original "there have
not been very many reports of libusb use on Windows at all"?

And let's say your statement was really about the impossibility of
estimating Windows usage "at all", then what was the point of it with
regards to interpreting the validity of Liam's report? It just doesn't
follow.

"Well, there's this thing we don't know. And then there's your report."

> I wrote nothing about how many people use libusb on Windows.

I beg to differ, as per the above.

> We can't
> know that. We can only know what we learn from actual feedback, and
> not many people have said that they use libusb on Windows.
>
> It could be hundreds of thousands, but it could also be ten-twenty.

Or -2 while we're at it. Unless you mean ten-twenty *thousands*, which
would actually be my lowest estimate (in which case you will have to
explain how 10-20 thousand is negligible as a user base)

For this, we can take a look at the latest download figures from
http://code.google.com/p/libusb-winusb-wip/downloads/list, where I
placed the libusb Windows binary archives.

I'm going to be somewhat ungenerous and assume that a vast majority of
the people who downloaded the previous archives will also have
downloaded the the latest one, and thus count only ~2000 unique user
downloads for the Windows binary, ever, in the 2 last years.

With Windows being experimental, and with quite a few more people
expected to want to pick up source rather than binary (since both are
advertised on the same page, and the library is obviously targeted at
developers), I also expect at least an order of magnitude higher rate of
people having compiled from git (but of course, you could have provided
a much better estimate of that if you had analysed clones of -pbatard
from your git server). And I have no idea what to make about possible
cygwin users.

So my estimate would probably be between 20,000 and 100,000 individual
users, for part of a project that was never actually officially released.

How's that for low expected rate of usage of the Windows backend?

> Maybe you'll agree that libusb and libusbx Windows support is still
> experimental though?

I never once said that it wasn't. If you actually bothered to pay
attention to the lists, you'll remember that I actually insisted on
flagging it as EXPERIMENTAL for the first few releases. And this is  how
it is tagged in libusbx.

Of course, the reason the Windows backend has to be flagged
experimental, after more than 2 years development is that someone sure
did their darnedest to prevent users from accessing in a convenient manner.

If you value SF downloads as much as you want to make us believe, now
that it's convenient for you to do so, and genuinely would like to have
seen increased usage reports and user feedback for the Windows backend
on the list, then why on earth did you drag your feet for 2 years before
reluctantly providing a release that includes Windows support there?

Also, as per
https://sourceforge.net/apps/mediawiki/libusbx/index.php?title=Main_Page#Supported_Environments,
yet another question you could easily have answered yourself.

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/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Orin Eman]

On Mon, Jun 18, 2012 at 4:56 PM, Peter Stuge <[hidden email]> wrote:

Peter Stuge wrote:
> Is there a reason why we would ever not want to set AUTO_CLEAR_STALL?
>
> It's done unconditionally now, which seems to be the right way to go
> so that the 31 error happens for one less reason.

On the other hand, do other backends automatically clear stalls? If
no then Windows also shouldn't. If that means that transfers will
complete with LIBUSB_ERROR_IO instead of LIBUSB_ERROR_NO_DEVICE
then I think that's OK. It's impossible to report what Windows
doesn't tell us.

It should be harmless to complete with LIBUSB_ERROR_IO if the device is removed.  I don't know what error WinUSB returns if you try to clear a 'stall' on a device that has been removed.  That would need research, but hopefully you get the 22 error.  Certainly, if a read is resubmitted to WinUSB with the device disconnected, you get the 22 error which as far as I know, can be translated into LIBUSB_ERROR_NO_DEVICE.

My current WinUSB code has a benign bug in that it doesn't notice a 31 error on a read completion.  It immediately resubmits the read, gets the 22 error and handles things correctly at that point.

There was an old thread on AUTO_CLEAR_STALL which google will bring up and the consensus then was to always set it.

Orin.

------------------------------------------------------------------------------
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/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Peter Stuge]

Pete Batard wrote:
> the API is really only one part of it

In a library the API is almost the only thing that matters. We've
long ago established that the libusb-1.0 API doesn't fit Windows and
that the Windows code has to jump through hoops because of that.


> balance API requirements with resources, as well as user requests...

An implementation needs to deliver what the interface promises.


Don't worry, Windows code is not getting any special treatment. If
there is talk about bugs in the Windows backend just now then it is
because they are being exposed just now. That seems likely,
considering that the first release is fairly recent, and users are
getting in touch.


> I'm reacting to your trying to pass your obvious *opinion*

I really can't help that you read something I do not write. I wish
you wouldn't, but you will of course continue to interpret me as you
choose.


> How is "there can be many users who do not have the same issue and for
> which everything is working" compatible with your original "there have
> not been very many reports of libusb use on Windows at all"?

You answer this yourself in the next sentence:

> let's say your statement was really about the impossibility of
> estimating Windows usage "at all",

I'm glad that you understand what I mean. I'm confused as to why you
ask me to clarify something that you already understand though.


> download figures

You can consider a download to be a report, but keep in mind that I don't.


> why on earth did you drag your feet for 2 years

I guess I can't do anything about this mad misconception. You know
how much time I've estimated to have spent on libusb, and it's
confusing that you would call that dragging one's feet.

If you think that I'm a liar or incapable of estimating time then
that's another matter of course, and then that is what you have to
state.


> before reluctantly providing a release

Another misconception. I'm really thrilled with libusb-1.0.9!


//Peter

------------------------------------------------------------------------------
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/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Pete Batard-2]

On 2012.06.19 08:28, Peter Stuge wrote:
> Pete Batard wrote:
>> the API is really only one part of it
>
> In a library the API is almost the only thing that matters.

Ergo, you are stating that the resources a project can muster, and users
requests don't matter, as per the exact elements I was bringing up.
Not a big surprise, but I'm glad you made that plain for everyone to see.

> We've
> long ago established that the libusb-1.0 API doesn't fit Windows and
> that the Windows code has to jump through hoops because of that.

Has nothing to do with the problem at hand. There's no technical
impossibility of fulfilling the 1.0 API requirements here. Just a matter
of doing it within a reasonable resource usage frame.

>> balance API requirements with resources, as well as user requests...
>
> An implementation needs to deliver what the interface promises.

...within the resources a project can master. This is the problem we
have, and that we've been having for years, but that you seemingly can't
grasp at all. If the resources aren't there, you can have the most
comprehensive and thought through API in the world, you're still only
gonna get a partial implementation.

And this is where implementing API features in the order where users
will get the most benefit out of it matters.

Let me illustrate this point further:
As a maintainer, would I want the recent topology calls of libusbx to be
implemented in the *BSD backend ASAP? Of course I would.
Am I going to request that soemone stop what they're doing with regards
to libusbx, and get them to go through that implementation so that we
satisfy the API requirements for *BSD? Of course not: having a partial
implementation of the API on *BSD for the time being takes second fiddle
to pressing matters that will benefit a lot more users.

The exact same thing holds for partial hotplug support in the Windows
backend.

> Don't worry, Windows code is not getting any special treatment.

Do extended integration delays not count as special treatment? Or are
you talking just now?

In that case, maybe the Windows *code* isn't, but if we judge by how
eager you are at tagging potential flaws in the Windows backend as bugs,
when practically none of these latest "bugs" you pointed out were the
result of unintended design, if actually deserving to be labelled as
bugs, I can't help but wonder...

Let me ask you this then: Had the platforms been reversed, and OS-X been
the OS where the discrepancy arose, would the content of your e-mail
have been similar in immediately pointing out a likely bug in the
backend, as well as dwelling on the amount of use report we get for OS-X
(or lack thereof, which would actually be accurate here, in comparison
with Linux and Windows) and how this impacts the likelihood of Liam's
report being meaningful? I seriously doubt that.

But do I have evidence to back this up? Pretty much. I could point for
instance to a case where, as per your usual stance, you highlighted a
specific behaviour of the Windows backend as unacceptable (had to do
with the backend returning an UNSUPPORTED error code on an API call),
but when provided with evidence that Windows had simply followed what
OS-X was doing in that respect, it magically ceased to be a contention
point.

Therefore, as long as I see repeated evidence that the Windows backend
is receiving "special" treatment from you, don't act too surprised to
see me (over)reacting to that.

> If
> there is talk about bugs in the Windows backend just now then it is
> because they are being exposed just now. That seems likely,
> considering that the first release is fairly recent, and users are
> getting in touch.

I dispute that. We have had 2 years of prior usage despite the lack of
release, and none of these so called bugs you tried to point out lately
were unintentional, if bugs at all.

If one looks at the libusbx git log [1], checks the entries tagged
Windows, considering the amount of "bugs" we're supposed to have raised
with the Windows backend lately, one will probably be astonished at the
apparent lack of bugfix commits.

The last actual bug, that was reported from a Windows user, and that
needed fixing was the "deadlock in backend when submitting transfers"
from Toby (a hard to reproduce one). Before that there was the usbi_fd
notification removal pointed out by Uri, but that was an easy to spot
regression introduced by an earlier code cleanup.

The longjpmp gcc 4.6 crash issue has little to do with something we
could have fixed beforehand, but everything to do with gcc changing its
default behaviour. And the other stuff is just items that we spotted
ourselves when running Clang or something, and not user inbound.

Then of course, there's that alleged serious bug with enumeration that
you got a report of on IRC, for which we still don't have a formal report...

For bugs that "are being exposed just now" in the Windows backend, we're
really short of patch fixes in git. Doesn't mean we aren't going to get
a serious bug uncovered by our users tomorrow, and of course you will
try to point out that I have been refusing to address behaviours, that
you qualify as bugs, but that were related to hotplug. Still, I can't
help but think that actual data to support your statement is a bit light.

>> I'm reacting to your trying to pass your obvious *opinion*
>
> I really can't help that you read something I do not write. I wish
> you wouldn't, but you will of course continue to interpret me as you
> choose.

I very much tried to quote what you did write.

>> How is "there can be many users who do not have the same issue and for
>> which everything is working" compatible with your original "there have
>> not been very many reports of libusb use on Windows at all"?
>
> You answer this yourself in the next sentence:

Except, in that next sentence, I'm pretty much saying that that I don't
see how it follows.

>> let's say your statement was really about the impossibility of
>> estimating Windows usage "at all",
>
> I'm glad that you understand what I mean. I'm confused as to why you
> ask me to clarify something that you already understand though.

Not at all. I don't understand how you can take the 2 previous
statements to mean the above, and I especially don't understand at all
how any of this was supposed to have any incidence on the validity of
Liam's report, which is the context in which you tried to use this
bullshit about Windows use reports. That is, unless you were somehow
trying to paint the Windows backend in a negative light.

>> download figures
>
> You can consider a download to be a report, but keep in mind that I don't.

Then why on earth did you suddenly start comparing SF downloads with
mailing list usage reports?

>> why on earth did you drag your feet for 2 years
>
> I guess I can't do anything about this mad misconception.

When you have been the sole project maintainer of libusb for about the
same amount of time, when that project, under the different very busy
maintainer, had little trouble releasing on semi-regular basis, and when
no releases were to be had until a fork occurred, it doesn't exactly
look like a mad misconception.

As the person in charge, the head of the project always takes the blame.
This holds true besides FLOSS. If you don't like that, then you should
consider adding other people at the head, to share potential blame with
you...

> You know
> how much time I've estimated to have spent on libusb,

And you know that I indicated that I most likely spent a lot more than
that myself, and how the amount one person allocates is quite irrelevant
with regards to the tasks towards which that time is actually allocated.

If any of us were to have spent all that time on beautifying the code,
or developing an libusb backend for the BeOS/Haiku platform, would it
matter in comparison to people who actually worked at producing a release?

> and it's confusing that you would call that dragging one's feet.

See above. Time is one thing. Using that time to actually produce
release and satisfy users is another. A lot of the time you invested or
wanted to see invested was on matters that didn't seem to be directly
beneficial for our users but when a forked release occurred, you somehow
managed to immediately go to release, even bypassing RC.

I think that leaves me with some ammunition to indeed qualify your
actions towards the 1.0.9 release as feet dragging. You have now
provided evidence that you could release on short notice. Yet, for
almost 2 years, and despite repeated requests from all sides, you failed
to produce one.

> If you think that I'm a liar or incapable of estimating time then
> that's another matter of course, and then that is what you have to
> state.

One again, if you don't invest that time in the right place, it hardly
matters how good you are at estimating it.

I don't think you're a liar. But I think you are clearly deluding
yourself with regards to the project's priorities, or even where your
priorities should stand as a maintainer (which is clearly highlighted
with placing the API requirements as absolute - users and project
resources be damned). I believe this has been, and continues to be,
hugely detrimental for libusb users.

>> before reluctantly providing a release
>
> Another misconception. I'm really thrilled with libusb-1.0.9!

Well, this is actually the one place where I was primarily talking about
time. Are you saying that you're thrilled with having released 1.0.9 the
day after libusbx was, and with not going through an RC?

Well, since you're so happy about releases, and I might as well try to
conclude with something that may benefit our users after all, a quick
question: when's 1.0.10 due?
Or is it difficult to estimate the time required for the next release
perhaps?

Regards,

/Pete

[1]
http://libusbx.git.sourceforge.net/git/gitweb.cgi?p=libusbx/libusbx;a=shortlog

------------------------------------------------------------------------------
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/
_______________________________________________
libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel