hotplug: Don't call the user callback while holding various locks

Calling user callbacks with locks held is a bad idea and should be avoided
whenever possible. Before this patch this could lead ie to the following hang:

1) User calls libusb_hotplug_register_callback with the
   LIBUSB_HOTPLUG_ENUMERATE flag
2) libusb_hotplug_register_callback calls the user callback while holding the
   hotplug_cbs_lock
3) The callback calls a synchronous libusb function
4) The synchronous libusb function calls libusb_handle_events
5) There is an hotplug event waiting in the hotplug pipe and
   libusb_handle_events calls usbi_hotplug_match
6) usbi_hotplug_match tries to take the lock a 2nd time
7) hang / assert / abort (depending on the platform)

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
hotplug: Document that callbacks cannot unregister themselves when called from hotplug_register_callback

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
hotplug: Document LIBUSB_HOTPLUG_ENUMERATE gotchas

When libusb_hotplug_register_callback gets called with the
LIBUSB_HOTPLUG_ENUMERATE flag, there may still be hotplug events pending
in the hotplug pipe, waiting for dispatching from libusb_handle_events.

This means that the user callback can be called twice for arrival of the
same device, once from libusb_hotplug_register_callback, since the device
is already part of the usb_devs list, and once from libusb_handle_events
when it reads the event from the hotplug pipe.

This could be fixed by adding a mechanism to pause hotplug handling, then
drain the hotplug pipe (ie by calling libusb_handle_events from
libusb_hotplug_register_callback), before iterating over the usb_devs list,
and then un-pausing hotplug handling afterwards, doing this however requires
a lot of hairy code, which will be prone to dead-locking.

OTOH it is quite simple for user applications which care about this to detect
this and ignore the 2nd call, so lets simply document this may happen and
be done with it.

Note that this is also the solution which ie libudev has choosen, there is
no way with libudev to get a device-list + listen for device arrival / removal
without running into the same problem.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
linux: Handle device disconnection early when possible

If a device is open, the device's fd will trigger a POLLERR condition
once it is removed. Sometimes this can occur well before the udev
monitor sends the remove event. This can also be caught early if
the device is not currently open but an attempt to open it is made.

In both situations, this can be caught early and processed so that
the device does not continue to show up in the device list after it
has been disconnected but before the udev monitor processes the event.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Clarify alignment requirements for the control transfer buffer

Since the buffer pointer will later be casted to ``struct
libusb_control_setup *'', it should point to memory aligned to at least
2 bytes boundary as that's the strictest requirement of the struct fields.

Also, use a (void *) casting trick to convince the compiler the cast is
safe, to fix warnings such as:

/usr/local/include/libusb-1.0/libusb.h: In function 'libusb_control_transfer_get_setup':
/usr/local/include/libusb-1.0/libusb.h:1435:9: error: cast increases required alignment of target type [-Werror=cast-align]
/usr/local/include/libusb-1.0/libusb.h: In function 'libusb_fill_control_setup':
/usr/local/include/libusb-1.0/libusb.h:1464:39: error: cast increases required alignment of target type [-Werror=cast-align]
/usr/local/include/libusb-1.0/libusb.h: In function 'libusb_fill_control_transfer':
/usr/local/include/libusb-1.0/libusb.h:1509:39: error: cast increases required alignment of target type [-Werror=cast-align]
cc1: all warnings being treated as errors

This actually can lead to failure to build from the sources for certain
projects which use -Werror=cast-align on ARM.

Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
openbsd: Split openbsd backend into separate openbsd and netbsd backends

Note the new netbsd_usb.c is an unmodified copy of openbsd_usb.c with
s/obsd/netbsd done on it. The reason for this split is that the openbsd
developers have been working on various improvements for their userspace
usb support, and adding support for those means breaking netbsd support,
by giving netbsd its own backend we can add support for the openbsd
improvements without breaking netbsd support.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
OpenBSD: Add basic support for non ugen(4) devices using usb(4)

It is now possible to have a read access and submit control transfers
to all USB devices using libusb, please note that controllers and hubs
also appear as devices.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Android: Add further documentation to Android README file

Signed-off-by: Hans de Goede <hdegoede@redhat.com>