[Libusbx-devel] Compiling on a fresh installation on Mac OS X

[Yves Arrouye]

Hi,

I was a bit surprised that the default installation obtained by cloning
(using git clone on the command line)
git://github.com/libusbx/libusbx.gitdid not include a configure or any
of the artifacts generated by the
autoconf suite.

Using a fresh cloned directory and having MacPort's autoconf and friends
first in my path (/opt/local/bin; those are later versions than Apple's), I
had to do the following (from the top level directory):

% mkdir m4
% autoreconf -v -i
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I m4
autoreconf: configure.ac: tracing
autoreconf: running: glibtoolize --copy
glibtoolize: putting auxiliary files in `.'.
glibtoolize: copying file `./ltmain.sh'
glibtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
glibtoolize: copying file `m4/libtool.m4'
glibtoolize: copying file `m4/ltoptions.m4'
glibtoolize: copying file `m4/ltsugar.m4'
glibtoolize: copying file `m4/ltversion.m4'
glibtoolize: copying file `m4/lt~obsolete.m4'
autoreconf: running: /usr/bin/autoconf
autoreconf: running: /usr/bin/autoheader
autoreconf: running: automake --add-missing --copy --no-force
configure.ac:42: installing `./compile'
configure.ac:39: installing `./config.sub'
configure.ac:29: installing `./missing'
configure.ac:29: installing `./install-sh'
configure.ac:39: installing `./config.guess'
examples/Makefile.am: installing `./depcomp'
autoreconf: Leaving directory `.'
%

Is that expected? If so, shouldn't the INSTALL file mentions that rather
than say that one should simply have to run configure? I see that
Makefile.in and other files are in the ignore file for git, so it does not
seem that you intend to distribute something that can be configured
directly with configure? Or I may be missing something quite obvious (it's
been a while since I've played with such builds).

Once I did this, it was pretty easy to build a proper library.

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

Re: [Libusbx-devel] Compiling on a fresh installation on Mac OS X

[Peter Stuge]

Yves Arrouye wrote:
> I was a bit surprised that the default installation obtained by cloning
> (using git clone on the command line)
> git://github.com/libusbx/libusbx.gitdid not include a configure

configure & co are generated and included in release tarballs. Since
they are generated files they do not belong in version control.


> Using a fresh cloned directory and having MacPort's autoconf and friends
> first in my path (/opt/local/bin; those are later versions than Apple's), I
> had to do the following (from the top level directory):
> 
> % mkdir m4
> % autoreconf -v -i
> 
> Is that expected?

libusb has always had the autogen.sh script which generates (and runs)
configure in a git tree. It works also with Mac OS X Xcode tools.


> If so, shouldn't the INSTALL file mentions that rather
> than say that one should simply have to run configure?

INSTALL is for tarball consumers. If you are a git consumer there are
further requirements.


> it does not seem that you intend to distribute something that can
> be configured directly with configure?

libusb certainly does not intend to put generated files under version
control, but it's possible that libusbx may want to change how this
works. I speak for the libusb project with my 8 years of experience
there, not for the libusbx fork of a few months which is ran by Pete.


> Or I may be missing something quite obvious

Maybe the autogen.sh script.


> Once I did this, it was pretty easy to build a proper library.

I think it is pretty easy to build libusb and libusbx, but working
with git does require more of you. I think that's a good thing not
per se, but because what is kept in git stays clean and easy to work
with, while the release process adds the generated files.

Pretty much the same as with every other proper library.


//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/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] Compiling on a fresh installation on Mac OS X

[Pete Batard]

Hi Yves,

On 2012.07.23 10:42, Yves Arrouye wrote:
> I was a bit surprised that the default installation obtained by cloning
> (using git clone on the command
> line) git://github.com/libusbx/libusbx.git
>  did not include a configure or
> any of the artifacts generated by the autoconf suite.

This is intended. Be mindful that the git repository is primarily aimed 
at libusbx development and not distribution. The tarballs we provide for 
each release do include configure.

Also note that what we're doing isn't libusbx specific. Many projects 
are set this way as well.

> Using a fresh cloned directory and having MacPort's autoconf and friends
> first in my path (/opt/local/bin; those are later versions than
> Apple's), I had to do the following (from the top level directory):

Instead, you should have invoked one of ./bootstrap.sh or ./autogen.sh, 
to do this for you. Again, these are fairly common invocation steps for 
autotools based projects.

We are also documenting this step on the wiki 
(https://github.com/libusbx/libusbx/wiki#wiki-Accessing_the_Source):

"Also note that, when compiling from git, you may have to run 
./autogen.sh or run the autotools creation utilities, in order to have 
configure and Makefile created for you."

> Is that expected? If so, shouldn't the INSTALL file mentions that rather
> than say that one should simply have to run configure?

The INSTALL file is aimed at the distribution tarball, that already 
comes with a configure file. I'm not sure we should mention git specific 
steps there, as it may confuse tarball users.

If you think it's important, we can create a specific readme for git 
users, to mention the need to run one of the scripts, and that wouldn't 
be included in the tarball.

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

Re: [Libusbx-devel] Compiling on a fresh installation on Mac OS X

[Pete Batard]

On 2012.07.23 11:30, Peter Stuge wrote:
> I speak for the libusb project with my 8 years of experience
> there, not for the libusbx fork of a few months which is ran by Pete.

How convenient of you to ignore the many years of experience myself (and 
the other admins) also have with libusb, as well as the fact that I am 
not the only one to run this project. I just happen to be the most 
active right now.

Also, as I already warned you, if you want to troll a project where you 
are only entitled to act as a regular member and disingenuously try to 
pooh-pooh its efforts (I have to say, your 8 years of experience 
certainly don't show with the messages above), you're going to earn 
yourself a ban.

> but working
> with git does require more of you. I think that's a good thing

Please keep this bullshit about how git is going to save the world to 
the libusb mailing list. This isn't the issue at hand, and this 
shoehorning of your opinion into issues that don't warrant it is also 
one of the reason libusbx had to fork from libusb.

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

Re: [Libusbx-devel] Compiling on a fresh installation on Mac OS X

[Peter Stuge]

Pete Batard wrote:
> you're going to earn yourself a ban.

That's confusing, but I guess you'll do as you like.


> > but working
> > with git does require more of you. I think that's a good thing
> 
> Please keep this bullshit about how git is going to save the world

I didn't write as verbosely as I could have, and you misunderstood.

>From the context that was the original poster's question it could
perhaps have been understood that what I intended was:

"but working with the code in git does require more of you"


> This isn't the issue at hand

Hopefully it's now clear that it is.


//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/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] Compiling on a fresh installation on Mac OS X

[Yves Arrouye]

> 
> libusb has always had the autogen.sh script which generates (and runs)
> configure in a git tree. It works also with Mac OS X Xcode tools.
> 

Okay. I personally do not build in the source tree (that tree is shared between 
my Mac environment and a Linux VM; I have also taken this habit as it is a 
great way to make sure my own projects behave well when built out of source 
tree). I think that generating the files and running the scripts at once is not 
a great separation of concerns, but I can understand that it is the mainstream 
case. Maybe a options autogen.sh could make it stop short of running configure? 
Or maybe autogen.sh can be invoked from out of source properly (I don't know 
and am away from my computer right now).

> 
>> If so, shouldn't the INSTALL file mentions that rather
>> than say that one should simply have to run configure?
> 
> INSTALL is for tarball consumers. If you are a git consumer there are
> further requirements.
> 

I think they could be listed somewhere. As long as OSS can be found easily,..

> 

Thanks to both Pete(r)s for replying quickly.

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

Re: [Libusbx-devel] Compiling on a fresh installation on Mac OS X

[Pete Batard]

On 2012.07.23 12:09, Peter Stuge wrote:
> That's confusing

It shouldn't be. There aren't many ways to interpret your intent behind 
your "with my 8 years of experience there, not for the libusbx fork of a 
few months which is ran by Pete", and they all point to trolling.

It has been explained to you multiple times how libusbx came into 
existence, and how I wasn't the one who pushed for it (not even behind 
the scenes, as Xiaofan and Travis will attest that I very much dropped 
the ball on a previous push for a fork that I was supposed to spearhead 
in mid 2011, because I remain extremely reluctant to the idea of 
forking). Of course, it is convenient for your dialectic to assert that 
I am the one who pushed for the fork, and that libusbx is my thing, 
regardless of how many time it is highlighted to you that this view 
isn't accurate.

A troll is someone who chooses to consistently ignore what is being 
pointed out to him, with the intent of spreading lies or half-truths. I 
think what you are doing above qualifies.

> I didn't write as verbosely as I could have, and you misunderstood.

I don't think that's the case. Elaborating, as you did, on how git keeps 
things "clean", "easy" and "good" is an unwarranted opinion that brings 
nothing to the equation, especially as Yves's question had already been 
answered by the time you replied.

Where did the issue become trying to convince Yves that using git (or 
another VCS for that matter) was better for him? We aren't going to 
switch to another VCS anytime soon, so git is what everybody will have 
to use. Therefore, trying to present the merits of git (or whatever VCS 
we pick) adds nothing.

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

Re: [Libusbx-devel] Compiling on a fresh installation on Mac OS X

[Pete Batard]

On 2012.07.23 12:23, Yves Arrouye wrote:
> Maybe a options autogen.sh could make it stop short of running configure?

As Peter isn't aware, because he isn't involved that closely in libusbx, 
we do have a bootstrap.sh that does the same as autogen.sh but doesn't 
run configure. I did mention both in my original reply, though I didn't 
highlight the difference, which I probably should have done.

I'll update the Wiki to make sure both are highlighted.

> I think they could be listed somewhere. As long as OSS can be found easily,..

What would be your preferred way?

Would and INSTALL.git do? Something else?

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

Re: [Libusbx-devel] Compiling on a fresh installation on Mac OS X

[Yves Arrouye]

Yes I read autogen.sh since I posted and saw what to does.

Sure, an INSTALL.git or even a README.git would be perfect (and a good
place to mention bootstrap vs autogen).

On Mon, Jul 23, 2012 at 1:39 PM, Pete Batard  wrote:

> On 2012.07.23 12:23, Yves Arrouye wrote:
> > Maybe a options autogen.sh could make it stop short of running configure?
>
> As Peter isn't aware, because he isn't involved that closely in libusbx,
> we do have a bootstrap.sh that does the same as autogen.sh but doesn't
> run configure. I did mention both in my original reply, though I didn't
> highlight the difference, which I probably should have done.
>
> I'll update the Wiki to make sure both are highlighted.
>
> > I think they could be listed somewhere. As long as OSS can be found
> easily,..
>
> What would be your preferred way?
>
> Would and INSTALL.git do? Something else?
>
> 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
>
--
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

Re: [Libusbx-devel] libusb segfaults - causes pcscd to crash

[sebastiank]

> On 2012.07.21 20:29, Ludovic Rousseau wrote:
> Can you try to make pcscd generate a core file?

Does this imply that the usbmon output is not useful and can be disabled?

> You may have to play with "ulimit -c unlimited" to allow the creation
> of a core file.

After doing some research about ulimit, I’m afraid to say that I can’t 
enable the generation of core dumps.
Firstly, the disk space available on the terminal computers is very limited
(I don’t know how much disk space will be used by a core dump, but there
are less than 2.5GB available). 
Secondly, enabling core dumps will require a system reboot (re-login should
work as well, but can’t be done by me or by the users), which is only 
possible on weekends.

=
Regards

Sebastian
=

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

Re: [Libusbx-devel] Compiling on a fresh installation on Mac OS X

[Pete Batard]

On 2012.07.23 12:49, Yves Arrouye wrote:
> Sure, an INSTALL.git or even a README.git would be perfect (and a good
> place to mention bootstrap vs autogen).

I think README.git is probably better as well. Will try to add one soon.

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

Re: [Libusbx-devel] libusb segfaults - causes pcscd to crash

[sebastiank]

> On 2012.07.23 13:51, sebastiank wrote:
>> On 2012.07.21 20:29, Ludovic Rousseau wrote:
>> You may have to play with "ulimit -c unlimited" to allow the creation
>> of a core file.
> After doing some research about ulimit, I’m afraid to say that I can’t 
> enable the generation of core dumps.

Well, maybe I found a solution to enable core dumps for the running pcscd 
process without the need of a reboot or re-login:

http://superuser.com/questions/404239/setting-ulimit-on-a-running-process

-
PID=$( pidof pcscd )
cat /proc/$PID/limits | grep -i -e "core file"
gdb -p $PID
(gdb) set $rlim = &{0ll, 0ll}
(gdb) print getrlimit(4, $rlim)
(gdb) print *$rlim
(gdb) set *$rlim[0] = -1
(gdb) print setrlimit(4, $rlim)
(gdb) quit
-

cat /proc/$PID/limits | grep -e "core file"
Before running gdb:
Max core file size  0 unlimited bytes
After running gdb:
Max core file size  unlimited unlimited bytes

=
Regards

Sebastian
=

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

Re: [Libusbx-devel] Compiling on a fresh installation on Mac OS X

[Peter Stuge]

Pete Batard wrote:
> Where did the issue become trying to convince Yves that using git
> (or another VCS for that matter) was better for him?

I don't know how you came up with the idea that I tried to do that.

Fortunately it didn't seem like Yves interpreted what I wrote like
you did.

Communication takes two people, and when messages are interpreted to
mean something else than what was intended, time after time and with
no interest for clarifications, then saying that the sender is
trolling seems an odd proposition.

Anyway - thanks for helping answer the original question!


//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/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

[Libusbx-devel] Async API question:

[Kevyn-Alexandre Paré]

Hi there,

Here's the code and output of my test. I'm trying to understand what's going 
wrong! I mean that I'm expecting the callback function "cb_xfr" from my bulk 
transfer to be called after libusb_submit_transfer is called. I'm communicating 
to a FPGA through a Cypress USB (FX2) and It's working with the synchronous API 
but not yet with the Asynchronous one??? I have put the usbmon output that I'm 
still reading and learning about it. If you see something let me know!

thx,

- KA
ps: code inspiration to do that test was from:
http://git.gnumonks.org/cgi-bin/gitweb.cgi?p=sam3u-tests.git;a=blob;f=usb-benchmark-project/host/benchmark.c



Here my test:


#include 
#include 
#include 
#include 
#include 
#include 

#include 
//#include 


#define EP_DATA_IN  0x82
#define EP_ISO_IN   0x86

static struct libusb_device_handle *devh = NULL;

static unsigned long num_bytes = 0, num_xfer = 0;
static struct timeval tv_start;

static void cb_xfr(struct libusb_transfer *xfr)
{
if (xfr->status != LIBUSB_TRANSFER_COMPLETED) {
fprintf(stderr, "--> transfer status %d\n", xfr->status);
libusb_free_transfer(xfr);
exit(3);
}

printf("--> length:%u, actual_length:%u\n", xfr->length, 
xfr->actual_length);
//printf("%s\n", osmo_hexdump(xfr->buffer, xfr->actual_length));
num_bytes += xfr->actual_length;
num_xfer++;

if (libusb_submit_transfer(xfr) < 0) {
fprintf(stderr, "-->error re-submitting URB\n");
exit(1);
}

}

static int benchmark_in(uint8_t ep)
{
static uint8_t buf[6] = {0x2,0xa0,0x3c,0x23,0x3,0x0};
static struct libusb_transfer *xfr;
int num_iso_pack = 0;

xfr = libusb_alloc_transfer(num_iso_pack);
if (!xfr)
return -ENOMEM;

libusb_fill_bulk_transfer(xfr, devh, ep, buf,
sizeof(buf), cb_xfr, NULL, 0);

gettimeofday(&tv_start, NULL);
printf("-->SUBMIT length:%d\n", sizeof(buf));
return libusb_submit_transfer(xfr);
}

static void measure(void)
{
struct timeval tv_stop;
unsigned int diff_msec;

gettimeofday(&tv_stop, NULL);

diff_msec = (tv_stop.tv_sec - tv_start.tv_sec)*1000;
diff_msec += (tv_stop.tv_usec - tv_start.tv_usec)/1000;

printf("--> %u transfers (total %u bytes) in %u miliseconds => %lu 
bytes/sec\n",
num_xfer, num_bytes, diff_msec, (num_bytes*1000)/diff_msec);
}

static void sig_hdlr(int signum)
{
switch (signum) {
case SIGINT:
measure();
exit(0);
break;
}
}

int main(int argc, char **argv)
{
int rc;

signal(SIGINT, &sig_hdlr);

rc = libusb_init(NULL);
if (rc < 0) {
fprintf(stderr, "--> Error initializing libusb\n");
exit(1);
}

devh = libusb_open_device_with_vid_pid(NULL, 0x09FB, 0x6001);
if (!devh) {
fprintf(stderr, "--> Error finding USB device\n");
exit(1);
}

rc = libusb_claim_interface(devh, 1);
if (rc < 0) {
fprintf(stderr, "--> Error claiming interface\n");
exit(1);
}


rc = libusb_set_interface_alt_setting(devh, 1, 0);
if (rc < 0)
{
fprintf(stderr, "--> Error alt setting\n");
exit(1);
}


unsigned char reply[2];
rc = libusb_control_transfer(devh,
 
LIBUSB_REQUEST_TYPE_VENDOR | LIBUSB_ENDPOINT_IN,
 0x93,
 0,
 0,
 reply,
 sizeof(reply),
 2000);
if (rc < 0)
{
fprintf(stderr, "--> Error control sync\n");
exit(1);
}

rc = libusb_control_transfer(devh,
 
LIBUSB_REQUEST_TYPE_VENDOR | LIBUSB_ENDPOINT_IN,
 0x95,
 0,
 1,
 reply,
 sizeof(reply),
 2000);
if (rc < 0)
{
fprintf(stderr, "--> Error control zero length packet\n");
exit(1);
}

Re: [Libusbx-devel] Async API question:

[Peter Stuge]

Kevyn-Alexandre Paré wrote:
> Here's the code and output of my test. I'm trying to understand
> what's going wrong! I mean that I'm expecting the callback function
> "cb_xfr" from my bulk transfer to be called after
> libusb_submit_transfer is called. I'm communicating to a FPGA
> through a Cypress USB (FX2) and It's working with the synchronous
> API but not yet with the Asynchronous one??? I have put the usbmon
> output that I'm still reading and learning about it. If you see
> something let me know!

I think the code looks fine. Try running against libusbx and/or
libusb git source. (It would be interesting to try both, in this
case.) http://libusb.org/wiki/debug has a cheat sheet for libusb,
which also works for libusbx as long as the repo URL is adjusted.


//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/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

[Libusbx-devel] liamstask opened issue 37 on libusbx/libusbx

[libusbx issues]

[liamstask][1] opened [issue 37][2] on [libusbx/libusbx][3] July 23, 2012

> v0.1.11, winusb backend: aborts do not succeed for open transfers on a
device that gets disconnected

   [1]: https://github.com/liamstask

   [2]: https://github.com/libusbx/libusbx/issues/37 (v0.1.11, winusb backend:
aborts do not succeed for open transfers on a device that gets disconnected)

   [3]: https://github.com/libusbx/libusbx

URL: https://github.com/libusbx/libusbx/issues/37

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

[Libusbx-devel] liamstask commented on issue 37 on libusbx/libusbx

[libusbx issues]

[liamstask][1] commented on [issue 37][2] on [libusbx/libusbx][3] July 24,
2012

> Ah, I see ERROR_FILE_NOT_FOUND does not get handled in
windows_transfer_callback() in windows_usb.c. Seems like cleaning up and
setting the transfer status to LIBUSB_TRANSFER_NO_DEVICE would be ideal, as
well as handling the corresponding scenario in winusb_abort_transfers().

>

> A bit more info: if I call libusb_exit() and libusb_init() once I've
detected this condition, it corrects itself but this is not a sufficient
workaround, since I'm handling multiple devices and would need to synchronize
their state with the state of the library, unless I used a separate context
for each device, which is not ideal :)

   [1]: https://github.com/liamstask

   [2]: https://github.com/libusbx/libusbx/issues/37#issuecomment-7195724
(v0.1.11, winusb backend: aborts do not succeed for open transfers on a device
that gets disconnected)

   [3]: https://github.com/libusbx/libusbx

URL: https://github.com/libusbx/libusbx/issues/37#issuecomment-7195724

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