darwin: avoid enumerating devices more than once

This patch attempts to avoid enumerating devices multiple times by
keeping a cache of device information (IOUSBDeviceInterface pointers,
device descriptors, etc) between calls to libusb_init(). This should
avoid two potential problems:

 1) Devices that respond slowly to DeviceRequest. These devices can
    take multiple seconds to respond and they usually respond with
    a failure (on older versions of OSX at least). By keeping track
    of these devices the penalty for enumerating them will be paid
    only once.
 2) Repeated enumeration of the same device may cause
    IOCreatePlugInInterfaceForService() to fail. The root cause of
    this problem is not well understood but might be a leak in
    IOUSBFamily.

To clean up the cached device information an atexit() function is
used.
darwin: increment the reference counter to the parent device
darwin: return correct error code from libusb_get_config_descriptor when the configuration is not found
Merge pull request #114 from hjelmn/darwin_device_cache

Darwin device cache
Core: Add a libusb_strerror() function

This patch adds the much requested libusb_strerror() function, taking into
account all issues people raised wrt previous attempts.

Criteria / Decisions underlying this implementation:
- Must support translated messages
- Must not use gettext as that does not work well in combination with Windows
 (when building with Visual C, or for Windows CE)
- API compatible with FreeBSD and various patched libusb-s floating around
- KISS:
 - Do not add any (other) library dependencies
 - Do not try to deal with message encodings (iconv), simply always return UTF-8
   making encoding the problem of the application using libusb_strerror.
 - Defaults to English, so apps which don't want translated messages,
   don't need to do anything special
 - Defaults to English (with pure ASCII messages), so apps which don't
   call libusb_setlocale() don't need to worry about encoding
Examples: add a missing \n at end of error messages
linux_udev: Log error code on pthread_create failure

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
hotplug: ensure udev monitor fd is non-blocking

Some older versions of udev do not automatically set the udev
monitor fd to non-blocking mode. This patch ensures that this is
always set.

HdG: Get flags then or in O_NONBLOCK and set them, rather then setting flags
to only O_NONBLOCK.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
libusb_get_bos_descriptor: Don't log an error on devices without a BOS

An error of LIBUSB_ERROR_PIPE simply means the device has no BOS, so don't
log an error to the console for this.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
linux_udev: Join the hotplug-event-thread when we stop event monitoring

To ensure that it is stopped before we continue (and if later libusb
gets re-initialized start another thread).

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
linux_udev: Don't free the udev_monitor while the event thread may still use it

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
POSIX: Set usbi_pipe to non-blocking by oring O_NONBLOCK to fd flags.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
linux_udev: Fix spelling of guarantee in comment

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
libusb: Add auto-detach-kernel-driver functionality

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>
linux_usbfs: Add support for new disconnect-and-claim ioctl

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>
linux_usbfs: Work around a driver binding race in reset handling

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>
examples: use libusb_set_auto_detach_kernel_driver()

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>
Fix several -Wconversion warnings from GCC inside the static inline functions.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Core: fix compiler warning in libusb_setlocale()

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>
Core: fix another compiler warning in libusb_setlocale()

* VS2012 (64 bit) produces the following in strerror.c(156):
  warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data