summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2013-07-30Add minimal config.h for XcodeLudovic Rousseau2-1/+29
Xcode do not use ./configure so the config.h file needs to be generated by hand. This config.h is the minimal file for libusbx built using Xcode.
2013-07-30Adapt Xcode project to the new pathsLudovic Rousseau2-3/+5
2013-07-30Move Xcode project in Xcode/ directoryLudovic Rousseau2-1/+1
This is to use Xcode special config.h file in a independent directory. The same is already done for MS Visual C with msvc/ directory.
2013-07-30Xcode projectLudovic Rousseau2-1/+789
2013-07-30linux_netlink: Remove use of pthread_cancelHans de Goede2-15/+45
Using pthread_cancel() presents the opportunity for deadlock, so use a control pipe to cause the event thread to gracefully exit. Inspired on the identical patch for linux_udev from Chris Dickens. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-07-30linux_netlink: close netlink socket on init errorHans de Goede2-1/+3
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-07-30hotplug: Remove use of pthread_cancel from linux_udevChris Dickens2-16/+49
Using pthread_cancel() presents the opportunity for deadlock, so use a control pipe to cause the event thread to gracefully exit. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-07-30linux: Use a separate lock to serialize start/stop vs hotplug eventsHans de Goede2-8/+18
Using one lock for this is a bad idea, as we should not be holding any locks used by the hotplug thread when trying to stop otherwise the stop function may wait indefinetely in pthread_join, while the event-thread is waiting for the lock the caller of the stop function holds. Using 2 separate locks for this should fix this deadlock, which has been reported here: https://bugzilla.redhat.com/show_bug.cgi?id=985484 Many thanks to Chris Dickens for figuring out the cause of this deadlock! CC: Chris Dickens <christopher.a.dickens@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-07-30work around Linux systems that don't provide SOCK_CLOEXEC or SOCK_NONBLOCKhjelmn2-2/+17
These options were added in 2.6.27 and are not available on all kernels that support netlink. Set these options using fcntl when SOCK_CLOEXEC and SOCK_NONBLOCK are not available. Closes #124.
2013-07-30fix warnings in linux_get_device_addresshjelmn2-9/+17
Warnings: os/linux_usbfs.c: In function 'linux_get_device_address': os/linux_usbfs.c:620: warning: comparison is always false due to limited range of data type os/linux_usbfs.c:624: warning: comparison is always false due to limited range of data type os/linux_usbfs.c:628: warning: comparison is always false due to limited range of data type os/linux_usbfs.c:628: warning: comparison is always false due to limited range of data type
2013-07-30include stdlib.h for free and realloc in libusbi.hhjelmn2-1/+3
References #124.
2013-07-30Silence automake 1.14 warningNathan Hjelm2-1/+3
The warning is: libusb/Makefile.am:57: warning: source file 'os/threads_windows.c' is in a subdirectory, libusb/Makefile.am:57: but option 'subdir-objects' is disabled automake: warning: possible forward-incompatibility. automake: At least a source file is in a subdirectory, but the 'subdir-objects' automake: automake option hasn't been enabled. For now, the corresponding output automake: object file(s) will be placed in the top-level directory. However, automake: this behaviour will change in future Automake versions: they will automake: unconditionally cause object files to be placed in the same subdirectory automake: of the corresponding sources. automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibilities. Fixed by setting the subdir-objects option. Closes #125.
2013-07-30Add checks for headers needed by linux/netlink.hNathan Hjelm3-6/+27
These headers are required by netlink.h. I am not sure how this worked at all. It certainly doesn't work with older versions of Linux 2.6. References #124.
2013-07-30keep a reference to the device for each active transfer and let the backend ↵Nathan Hjelm3-13/+5
handle cancelling active transfers when a device is disconnected This commit should fix issues with active transfers when a device is disconnected. The backend is responsible for making sure the completion callbacks are made, not the hotplug code. This should fix a number of issues including duplicate callbacks and segmentation faults. References #124.
2013-07-23hotplug: Pass explicit context to callbacksFlorian Albrechtskirchinger2-3/+2
* Instead of passing NULL for the context to hotplug callbacks, if the context happens to be the default context, always pass the explicit context pointer.
2013-07-11Prepare for 1.0.16 final releaseHans de Goede3-3/+3
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-07-06Prepare for 1.0.16-rc3 releaseHans de Goede3-3/+4
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-07-05Documentation: add an Using an event handling thread sectionHans de Goede2-4/+63
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-07-05Documentation: explain the 2 main viable event handling approachesHans de Goede2-34/+31
Stop pretending that having a separate event handling thread is a bad thing, specifically delete the "[this] option is not very nice either, but may be the nicest option available to you if the "proper" approach can not be applied to your application", which suggests that using poll integration into a main loop is the one and only "proper" approach. Instead clearly document there are 2 viable approaches, using a separate thread, or poll integration into a main loop. Also stop claiming that libusb does not use threads internally, as with the new hotplug support this is no longer true. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-07-05hotplug: Wakeup libusb_handle_events on libusb_hotplug_deregister_callbackHans de Goede2-1/+10
This serves 2 purposes: 1) We use lazy free-ing of the callback structure, for it to be actually free-ed usbi_hotplug_match() needs to be called. This ensures this actually happens (rather then waiting for a hotplug event to arrive, and not freeing the callback as long as no such event arrives). 2) It causes libusb_handle_events to return to its caller on a call to libusb_hotplug_deregister_callback, which is very useful for apps which use a thread to do their apps (hotplug) event handling, otherwise that thread will hang when the app tries to stop until some event happens. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-07-05hotplug: Give the usbi_hotplug_match* functions a context parameterHans de Goede4-11/+11
So that the device parameter can be NULL, in combination with a 0 events parameter, to be used to force lazy deregistration. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-07-04Doc: update hotplug, topology and descriptor documentationPete Batard5-16/+36
* Also fix some typos * Closes #95
2013-07-01Prepare for 1.0.16-rc2 releaseHans de Goede4-3/+6
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-06-30Core: Use fputs(3) instead of fprintf(3)Tim Roberts2-2/+2
This is a micro-optimisation, but it should make the code easier to understand.
2013-06-30Core: Fix writing of log lines a single fprintf callPete Batard3-19/+15
* fb4c208c33788068bbca67bdd6d11127b5be5a26 broke cygwin compilation due to __GCC__ not being defined * The actual issue is that __GNUC__ rather than __GCC__ should have been used all along * Also fixes gettimeofday() usage for MinGW/Cygwin * Also increase log buffer size to 1K, fix a broken fprintf in core.c and sort whitespaces
2013-06-27Core: Make writing of log lines a single fprintf call.Toby Gray3-8/+45
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 output to in the future. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-06-27core: Always warn when there are leaked device refs on exitHans de Goede2-5/+6
This check should done with hotplug capable backends too. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-06-26Core: Avoid passing uninitialised data down the hotplug pipe.Toby Gray2-1/+3
Due to alignment requirements, libusb_hotplug_message might have some padding bytes. This change makes sure that these padding bytes are initialised. Valgrind no longer complains about passing uninitialised data to the write system call. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-06-26core.c: Initialize auto_detach_kernel_driver to 0 for new handleChris Dickens2-1/+2
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-06-26openbsd: Fix memleak in obsd_get_device_list()Hans de Goede2-2/+6
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-06-26core: Only do hotplug cleanup for hotplug capable backendsHans de Goede2-9/+11
Xiaofan encountered a crash while testing on openbsd. The main problem here is libusb_exit doing hotplug cleanup on a non hotplug capable backend. If the usb_devs list is non empty (*) at libusb_exit time with a non hotplug capable backend, then the hotplug cleanup code will unref the devices in the list. Assuming this is the last unref, then libusb_unref_device will call usbi_disconnect_device, which will try to take the usb_devs_lock, which is already hold by libusb_exit. Note that if this deadlock was not there, that we then also would have a double list_del issue. *) This should never happen, if it does either libusb or the app has a memleak, or the app still holds a reference to the device. The latter is an application bug, since device->ctx will be invalid after libusb_exit, so the application should not hold references after calling libusb_exit. In this case we have a memleak the libusb openbsd code causing the usb_devs list to be non empty. This will be fixed in another commit. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-06-26WinCE: ref result of usbi_get_device_by_session_id()Hans de Goede2-1/+2
After the "WinCE: Fix device reference leak which caused crash on libusb_exit()" commit, the code always unref-s dev after adding it to discovered_devs. But if dev comes from usbi_get_device_by_session_id() it is a weak ref and as such should not be unreffed. Instead of re-adding comlicate ref tracking logic, this patch fixes this with a libusb_device_ref(dev) of dev comes from usbi_get_device_by_session_id(), turning the weak ref into a strong ref. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-06-26WinCE: Fix device reference leak which caused crash on libusb_exit().Toby Gray2-7/+5
The Windows CE device allocation code has always had a bug where it would leak references to devices when they are allocated. This commit removes the reference leak. This leak was highlighted by the new hotplug code which now triggers a NULL pointer dereference if not all devices are unreferenced before libusb_exit is called. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-06-20Misc: Update AUTHORS filePete Batard2-3/+5
2013-06-20Prepare for 1.0.16-rc1 releaseHans de Goede4-3/+23
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-06-20autogen.sh: Honor NOCONFIGURE=1Colin Walters2-2/+4
See http://people.gnome.org/~walters/docs/build-api.txt Hdg: I know this may seem unnecessary since we also have bootstrap.sh, but the Gnome people are doing continues build testing of Gnome + dependencies and having all autogen.sh scripts support NOCONFIGURE=1 makes live easier for them. Note that in return we get "free" continues build-testing and patches and / or a heads up when we break things. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-06-20sync.c: Remove code duplicationHans de Goede2-36/+24
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-06-20sync.c: Do not free an incompleted transferHans de Goede2-11/+9
Before this patch the code in sync.c would free an incomplete transfer when libusb_handle_events_completed exits with an error twice in a row. But we should never free an incomplete transfer, otherwise we may end up referencing free-ed memory later on. This patch simply logs an error and keeps on trying until the transfer completes. Note that if libusb_handle_events_completed keeps throwing an error the entire time, without ever completing the transfer, this patch effectively replaces a potential crash / unspecified behavior, with an endless loop and logging a ton of errors making clear what is going on. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-06-20Revert "Core: Don't wait for completion if cancel_transfer failed"Hans de Goede2-11/+9
This reverts commit 2f5023c41d3176e56bf0abc521b7c5f8b1ac4664. 2f5023c4 was an attempt to fix: https://github.com/libusbx/libusbx/issues/76 As seen in: http://libusbx.1081486.n5.nabble.com/Libusbx-devel-libusb-interrupt-transfer-does-not-return-in-case-of-error-td626.html [372849.680990] [0000275b] libusbx: error [reap_for_handle] reap failed error -1 errno=14 [372849.681752] [0000275b] libusbx: error [handle_events] backend handle_events failed with error -1 [372850.680466] [0000275b] libusbx: warning [handle_timeout] async cancel failed -5 errno=22 The problem begins with reap_for_handle failing with errno == 14, which is EFAULT. So the real problem is the application passing in an invalid (or too short) buffer, and thus is an application bug. The fix masks this problem, but causes the problem of calling libusb_transfer_free() on a non finished transfer, so it is no good. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Conflicts: AUTHORS libusb/version_nano.h
2013-06-20Use Android logging when building on AndroidIlya Konstantinov2-1/+28
Closes #101 Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-06-20Linux: Fix get_kernel_driver_active() when another app has claimed the interfaceHans de Goede2-2/+2
When another app has claimed the interface, IOCTL_USBFS_GETDRIVER will succeed and report a driver of "usbfs" being attached. Since this is not a regular kernel-driver (and detach_kernel_driver does not detach it), get_kernel_driver_active() should return 0 in this case. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-06-19Core: fix another compiler warning in libusb_setlocale()Pete Batard2-2/+2
* VS2012 (64 bit) produces the following in strerror.c(156): warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data
2013-06-19Core: fix compiler warning in libusb_setlocale()Ludovic Rousseau2-2/+2
Hello, A small patch for: strerror.c: In function 'libusb_setlocale': strerror.c:148: warning: comparison between signed and unsigned strerror.c:152: warning: comparison between signed and unsigned -- Dr. Ludovic Rousseau From a4144845845cd0a06fb9074ba2d6669ece3a5b1a Mon Sep 17 00:00:00 2001 From: Ludovic Rousseau <ludovic.rousseau+github@gmail.com> Date: Wed, 19 Jun 2013 13:16:31 +0200 Subject: [PATCH] Core: fix compiler warning in libusb_setlocale() strerror.c: In function 'libusb_setlocale': strerror.c:148: warning: comparison between signed and unsigned strerror.c:152: warning: comparison between signed and unsigned Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-06-19Fix several -Wconversion warnings from GCC inside the static inline functions.Luca Longinotti2-10/+10
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-06-19examples: use libusb_set_auto_detach_kernel_driver()Hans de Goede3-26/+3
What better way to show how useful libusb_set_auto_detach_kernel_driver() is, then to use it in our examples? Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-06-19linux_usbfs: Work around a driver binding race in reset handlingHans de Goede2-3/+11
I've been seeing these intermittent failures to reclaim an interface after a device reset. After much debugging and inserting sleeps in strategic places to make the race window larger I've found the following race: 1) A user is running some software using libusbx which will automatically detect, and "bind" to, any newly plugged in USB-devices. For example a virtual machine viewer with automatic USB-redirection 2) The user plugs in a new usb-storage device 3) The usb-storage driver is not yet loaded, udev spawns "modprobe usb-storage", this blocks on disk-io 4) The libusbx app opens the device, claims all interfaces, does a device-reset 5) While the IOCTL_USBFS_RESET is running the modprobe completes 6) The driver registration blocks on an USB lock held by the reset code path 7) When the reset finishes the driver registration completes and the driver binds itself to the device, before IOCTL_USBFS_RESET returns to userspace 8) libusbx tries to re-claim all interfaces it had claimed before the reset 9) libusbx fails as usb-storage is now bound to it This patch works around this issue by simply unbinding the driver for all interfaces which were claimed before the reset. Normally this is a no-op as no driver (other then usbfs) can be bound for claimed interfaces before the reset. This patch also improves the error logging, and makes libusb_device_reset properly return an error when re-claiming fails. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-06-19linux_usbfs: Add support for new disconnect-and-claim ioctlHans de Goede3-2/+36
Currently the linux_usbfs detach_kernel_driver_and_claim() helper function makes 3 system calls: 1) IOCTL_USBFS_GETDRIVER, to check the driver is not usbfs 2) IOCTL_USBFS_DISCONNECT 3) IOCTL_USBFS_CLAIMINTF Between each of these calls the state of the interface can change, and things might not work as expected when it does, iow this is inherently racy. To fix this a new IOCTL_USBFS_DISCONNECT_CLAIM ioctl has been added to the kernel a while back, which does all 3 in one. This patch adds support for this ioctl, with a fall back to the old method for kernels lacking this new ioctl. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-06-19libusb: Add auto-detach-kernel-driver functionalityHans de Goede6-6/+93
Add auto-detach-kernel-driver functionality, and a libusb_set_auto_detach_kernel_driver() function. Note that I went with a libusb_set_auto_detach_kernel_driver() function, rather then with a libusb_enable_auto_detach_kernel_driver(), so that apps can also disable it again. This is necessary to handle 2 corner cases: 1) When an app wants to do a libusb_set_configuration after claiming 1 or more interfaces, it needs to first release the interface(s), and in this case libusb_release_interface() should *not* (re-)attach the kernel driver 2) Some usb classes use multiple interfaces for one function, ie usb-audio devices do this. In this case attaching the driver will fail until all interfaces are released, so the app should first release all interfaces, and only then (re-)attach the kernel driver. auto-detach-kernel-driver functionality is still useful for these apps, since doing libusb_detach_kernel_driver() followed by libusb_claim_interface() in 2 separate calls is inherently racy, but they need to be able to disable the auto-detach functionality before releasing interfaces to be able to properly handle the 2 described corner cases. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-06-19linux_udev: Fix spelling of guarantee in commentHans de Goede2-2/+2
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2013-06-17POSIX: Set usbi_pipe to non-blocking by oring O_NONBLOCK to fd flags.Chris Dickens2-4/+14
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-20 03:55:06 +0000