Re: [Libusbx-devel] umask affects libusb_attach_kernel_driver()

Hi On 06/26/2013 09:17 PM, Chris Dickens wrote: > Yes, devtmpfs. Linux Kernel is 2.6.32-358 (RHEL6). Ok likely a kernel issue then. You should probably retry with a more recent kernel (ie try on a Fedora 18 install), and then file a bug either against the upstream kernel, or against RHEL-6. Rega

Re: [Libusbx-devel] Improving linux hotplug disconnect

Hi, On 06/26/2013 06:57 PM, Chris Dickens wrote: > Hi, > > On Wed, Jun 26, 2013 at 8:34 AM, Hans de Goede > wrote: > > Hi, > > Hmm, the libusb_poll call in get_device_list() should make this quite > hard to trigger, this will only > happen if udev has not

[Libusbx-devel] Improved logging

I've made a couple of changes to the logging in libusbx. The first is to make a single fprintf call for each log line, as suggested by Chris Dickens. The second change makes it possible to enable logging output in Windows to go to the debugger. This makes it considerably easier to debug issues in

[Libusbx-devel] [PATCH 2/2] Windows: Make ENABLE_DEBUG_LOGGING enable logging output to the debugger.

This change makes it considerably easier to debug issues in UI applications which don't necessarily have a console connected to stderr. Outputting to the debugger shouldn't occur in normal situations so this change has to be explicitly enabled by a build-time config flag. --- libusb/core.c | 10

[Libusbx-devel] [PATCH 1/2] Core: Make writing of log lines a single fprintf call.

--- libusb/core.c| 40 +--- libusb/libusbi.h | 10 ++ 2 files changed, 43 insertions(+), 7 deletions(-) diff --git a/libusb/core.c b/libusb/core.c index bc44415..5c93f4b 100644 --- a/libusb/core.c +++ b/libusb/core.c @@ -2017,12 +2017,19 @@ int

Re: [Libusbx-devel] [PATCH 1/2] Core: Make writing of log lines a single fprintf call.

Hi, A (v)snprintf return of -1 means that the output was truncated (on some libc-s) throwing away the header if that got truncated somehow is fine, but throwing away the log message is not. Thus I would like to suggest replacing: > + text_len = vsnprintf(buf + header_len, sizeof(buf) - head

Re: [Libusbx-devel] [PATCH 1/2] Core: Make writing of log lines a single fprintf call.

On 27/06/13 13:25, Hans de Goede wrote: > Hi, > > > > A (v)snprintf return of -1 means that the output was truncated > (on some libc-s) throwing away the header if that got truncated > somehow is fine, but throwing away the log message is not. I'd forgotten that some libc-s return -1 meaning trun

[Libusbx-devel] Improved logging v2

This is a slightly reworked version of my previous logging patches. I've improved the commit message for the first patch and made the changes suggested by Hans de Goede relating to return value of snprintf calls. Regards, Toby ---

[Libusbx-devel] [PATCH v2 2/2] Windows: Make ENABLE_DEBUG_LOGGING enable logging output to the debugger.

This change makes it considerably easier to debug issues in UI applications which don't necessarily have a console connected to stderr. Outputting to the debugger shouldn't occur in normal situations so this change has to be explicitly enabled by a build-time config flag. --- libusb/core.c | 10

[Libusbx-devel] [PATCH v2 1/2] Core: Make writing of log lines a single fprintf call.

Prior to this change a single line of logging performing several fprintf. This change gets all the data for a line to be logged in a single fprintf call. This reduced the chances of writes from another thread getting intermixed with a log line. It also makes it easier to change where logs are out

Re: [Libusbx-devel] [PATCH 1/2] Core: Make writing of log lines a single fprintf call.

Hi, On 06/27/2013 03:16 PM, Toby Gray wrote: > On 27/06/13 13:25, Hans de Goede wrote: >> Hi, >> >> >> >> A (v)snprintf return of -1 means that the output was truncated >> (on some libc-s) throwing away the header if that got truncated >> somehow is fine, but throwing away the log message is not.

Re: [Libusbx-devel] Improved logging v2

Hi, On 06/27/2013 03:49 PM, Toby Gray wrote: > > This is a slightly reworked version of my previous logging patches. > > I've improved the commit message for the first patch and made the > changes suggested by Hans de Goede relating to return value of > snprintf calls. Thanks, I've pushed the 1st

Re: [Libusbx-devel] Improved logging v2

On 27/06/13 16:15, Hans de Goede wrote: Hi, On 06/27/2013 03:49 PM, Toby Gray wrote: This is a slightly reworked version of my previous logging patches. I've improved the commit message for the first patch and made the changes suggested by Hans de Goede relating to return value of snprintf ca

Re: [Libusbx-devel] Improving linux hotplug disconnect

Hi, On Thu, Jun 27, 2013 at 3:31 AM, Hans de Goede wrote: > Hi, > > +/* device will still be marked as attached if hotplug monitor thread >> +* hasn't processed remove event yet */ >> +if (handle->dev->attached) { >> > > This check is racy, you need to take the hotplug lock before making this

[Libusbx-devel] [PATCH 10/11] Windows: Pre-reserve pollfds before submitting transfers.

This change makes the Windows and Windows CE backend pre-reserve pollfds before submitting transfers. This allows these backends to correctly handle failure to reserve pollfds. Prior to this change both backends ignored the return value from usbi_add_pollfds. --- libusb/os/wince_usb.c | 13 ++

[Libusbx-devel] [PATCH 07/11] Tests: Add test for 64 concurrent control requests.

This test is being added to provoke MAXIMUM_WAIT_OBJECTS on Windows platforms. Currently the synchronous transfer in this test hangs on Windows platforms. This is due to the following sequence of events: * There are more than MAXIMUM_WAIT_OBJECTS event objects to wait for. * WaitForMultipleObject

[Libusbx-devel] [PATCH 08/11] Core: Cache the number of pollfds.

Previously it was necessary to count the number of pollfds contained in a linked list. This change introduces the optimisation of storing a running total of the number of pollfds. --- libusb/io.c | 16 libusb/libusbi.h |1 + 2 files changed, 9 insertions(+), 8 deletions

[Libusbx-devel] [PATCH 03/11] Core: Add new cross-platform event handling API

This change adds the API and some stub implementations of a new cross platform supporting event API. --- libusb/io.c | 78 - libusb/libusb-1.0.def |4 +++ libusb/libusb.h | 65 + libusb/

[Libusbx-devel] [PATCH 05/11] Windows: Change Windows poll code to use libusb_event_handle

This updates the common poll code used by Windows and Windows CE to use the libusb_event_handle typedef instead of int for file descriptors. --- libusb/os/poll_windows.c |8 libusb/os/poll_windows.h | 10 +- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/libu

[Libusbx-devel] [RFC] Remove fake fds from Windows backends

I realise that 1.0.16 is currently trying to be released and that these patches won't get looked at until after that has happened. I'm away from the office for the next couple of weeks so thought it was worth sending this patch series for people to look at if they get time while I'm away. A while

[Libusbx-devel] [PATCH 04/11] Core: Change pollfds over to using libusb_event_handle instead of int

This change makes the internals of libusb make use of the libusb_event_handle typedef instead of int when dealing with file descriptors. --- libusb/io.c | 123 +++--- libusb/libusb.h |5 ++- libusb/libusbi.h | 10 ++--- 3 files changed,

[Libusbx-devel] [PATCH 06/11] Windows: Get rid of fake FDs use inside Windows and Window CE backends

This change removes the fake FDs and replaces them with event handles. --- libusb/os/poll_windows.c | 466 -- libusb/os/poll_windows.h | 10 +- libusb/os/wince_usb.c| 14 +- libusb/os/windows_usb.c | 53 -- 4 files changed, 118 insertions

[Libusbx-devel] [PATCH 11/11] Windows: Set limit of pollfds for Windows and Windows CE.

Both the Windows and Windows CE backends use MultipleWaitForObjects in their usbi_poll implementations. This function has a limited number of objects it can wait on. This commit configures libusb to the correct limit for maximum pollfds. --- configure.ac |1 + msvc/config.h |3 +++ 2 fil

[Libusbx-devel] [PATCH 01/11] Tests: Adding ability for tests to use setjmp and longjmp for status reporting

This improves the testlib used in libusbx to allow tests to either return the test status or to call a function which never returns. This leads to simpler test code as nested functions do not have to return test status up the calling chain. --- tests/libusbx_testlib.h | 54 +

[Libusbx-devel] [PATCH 09/11] Core: Allow backends to reserve pollfds.

This adds in new internal APIs to allow backends to reserve the pollfds which will be added to the pollfds linked list. This also adds a new function for adding pre-reserved pollfds to the pollfds linked list. This function can never fail, unlike the standard usbi_add_pollfds(). --- libusb/io.c

Re: [Libusbx-devel] Improved logging v2

On 2013.06.27 16:15, Hans de Goede wrote: > Thanks, I've pushed the 1st patch, Dammit Hans, can we please avoid [r|p]ushing _new_ core features when we're smack down the middle of an RC? Or at least, if you deem we really must have them, can you wait at least 24 hours before committing, so that

Re: [Libusbx-devel] Improved logging v2

Hi, On 06/27/2013 07:15 PM, Pete Batard wrote: On 2013.06.27 16:15, Hans de Goede wrote: Thanks, I've pushed the 1st patch, Dammit Hans, can we please avoid [r|p]ushing _new_ core features when we're smack down the middle of an RC? Or at least, if you deem we really must have them, can you wa

Re: [Libusbx-devel] Improving linux hotplug disconnect

Hi, On 06/27/2013 06:22 PM, Chris Dickens wrote: > Hi, > > > On Thu, Jun 27, 2013 at 3:31 AM, Hans de Goede > wrote: > > Hi, > > +/* device will still be marked as attached if hotplug monitor thread > +* hasn't processed remove event yet */ >

Re: [Libusbx-devel] [RFC] Remove fake fds from Windows backends

Hi, Cool stuff, thanks! I believe this is best reviewed by Pete though, hopefully he can find some time for this in the not too distant feature. Enjoy your vacation / away from the office time :) Regards, Hans On 06/27/2013 06:58 PM, Toby Gray wrote: > > I realise that 1.0.16 is currently tryi

Re: [Libusbx-devel] Improved logging v2

Hans de Goede wrote: > You're right, and I'm sorry. I guess I'm to much of a rero person sometimes. > > Although win32 is far from my specialty I think the attach patch should fix > it. Any chance you could give it a try? This is micro-optimization, of course, but it would be more efficient to do

Re: [Libusbx-devel] Improved logging v2

On 2013.06.27 19:33, Hans de Goede wrote: > I think the attach patch should fix it. Any chance you could give it a try? Tested. Same failure. This isn't the issue (though yes, we want to fix that too). The issue, as I pointed in my last e-mail, is https://github.com/libusbx/libusbx/blob/master/l