Re: [Libusbx-devel] Major problems using libusbx on CentOS 5
Hi Judd,
Attached is a patch to remove hotplug functionality from the Linux backend,
while still retaining all other fixes. This essentially gives you 1.0.18
without hotplug.
If you have time to try it, please let me know how it works out.
Chris
From c79d3eec1a54ea2f2da4a383d1f186fa9587 Mon Sep 17 00:00:00 2001
From: Chris Dickens christopher.a.dick...@gmail.com
Date: Thu, 30 Jan 2014 01:40:55 -0800
Subject: [PATCH] Remove hotplug functionality for Linux backend.
---
configure.ac| 21
libusb/Makefile.am | 10 +-
libusb/os/linux_usbfs.c | 253 ++--
libusb/os/linux_usbfs.h | 22 -
4 files changed, 73 insertions(+), 233 deletions(-)
diff --git a/configure.ac b/configure.ac
index 3495acf..5063e6e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -98,26 +98,6 @@ linux)
AC_DEFINE(OS_LINUX, 1, [Linux backend])
AC_SUBST(OS_LINUX)
AC_SEARCH_LIBS(clock_gettime, rt, [], [], -pthread)
- AC_ARG_ENABLE([udev],
- [AC_HELP_STRING([--enable-udev], [use udev for device enumeration and hotplug support (recommended) [default=yes]])],
- [], [enable_udev=yes])
- if test x$enable_udev = xyes ; then
- # system has udev. use it or fail!
- AC_CHECK_HEADERS([libudev.h],[],[AC_ERROR([udev support requested but libudev not installed])])
- AC_CHECK_LIB([udev], [udev_new], [], [AC_ERROR([udev support requested but libudev not installed])])
- AC_DEFINE(USE_UDEV, 1, [Use udev for device enumeration/hotplug])
- else
- AC_CHECK_HEADERS([asm/types.h sys/socket.h], [], [])
- AC_CHECK_HEADERS([linux/netlink.h linux/filter.h], [], [AC_ERROR([Linux netlink headers not found])], [
-#ifdef HAVE_ASM_TYPES_H
-#include asm/types.h
-#endif
-#ifdef HAVE_SYS_SOCKET_H
-#include sys/socket.h
-#endif
-])
- fi
- AC_SUBST(USE_UDEV)
case $is_backend_android in
yes)
@@ -180,7 +160,6 @@ AM_CONDITIONAL(OS_NETBSD, test x$backend = xnetbsd)
AM_CONDITIONAL(OS_WINDOWS, test x$backend = xwindows)
AM_CONDITIONAL(THREADS_POSIX, test x$threads = xposix)
AM_CONDITIONAL(CREATE_IMPORT_LIB, test x$create_import_lib = xyes)
-AM_CONDITIONAL(USE_UDEV, test x$enable_udev = xyes)
if test $threads = posix; then
AC_DEFINE(THREADS_POSIX, 1, [Use POSIX Threads])
fi
diff --git a/libusb/Makefile.am b/libusb/Makefile.am
index 80e3705..e842fc4 100644
--- a/libusb/Makefile.am
+++ b/libusb/Makefile.am
@@ -19,15 +19,7 @@ EXTRA_DIST = $(LINUX_USBFS_SRC) $(DARWIN_USB_SRC) $(OPENBSD_USB_SRC) \
os/linux_udev.c os/linux_netlink.c
if OS_LINUX
-
-if USE_UDEV
-OS_SRC = $(LINUX_USBFS_SRC) $(POSIX_POLL_SRC) \
- os/linux_udev.c
-else
-OS_SRC = $(LINUX_USBFS_SRC) $(POSIX_POLL_SRC) \
- os/linux_netlink.c
-endif
-
+OS_SRC = $(LINUX_USBFS_SRC) $(POSIX_POLL_SRC)
endif
if OS_DARWIN
diff --git a/libusb/os/linux_usbfs.c b/libusb/os/linux_usbfs.c
index a95d099..50bf89d 100644
--- a/libusb/os/linux_usbfs.c
+++ b/libusb/os/linux_usbfs.c
@@ -118,23 +118,8 @@ static int sysfs_can_relate_devices = -1;
* descriptors file, so from then on we can use them. */
static int sysfs_has_descriptors = -1;
-/* how many times have we initted (and not exited) ? */
-static volatile int init_count = 0;
-
-/* Serialize hotplug start/stop */
-usbi_mutex_static_t linux_hotplug_startstop_lock = USBI_MUTEX_INITIALIZER;
-/* Serialize scan-devices, event-thread, and poll */
-usbi_mutex_static_t linux_hotplug_lock = USBI_MUTEX_INITIALIZER;
-
-static int linux_start_event_monitor(void);
-static int linux_stop_event_monitor(void);
-static int linux_scan_devices(struct libusb_context *ctx);
-static int sysfs_scan_device(struct libusb_context *ctx, const char *devname);
static int detach_kernel_driver_and_claim(struct libusb_device_handle *, int);
-
-#if !defined(USE_UDEV)
-static int linux_default_scan_devices (struct libusb_context *ctx);
-#endif
+static int sysfs_scan_device(struct libusb_context *ctx, struct discovered_devs **_discdevs, const char *devname);
struct linux_device_priv {
char *sysfs_dir;
@@ -422,78 +407,7 @@ static int op_init(struct libusb_context *ctx)
if (sysfs_has_descriptors)
usbi_dbg(sysfs has complete descriptors);
- usbi_mutex_static_lock(linux_hotplug_startstop_lock);
- r = LIBUSB_SUCCESS;
- if (init_count == 0) {
- /* start up hotplug event handler */
- r = linux_start_event_monitor();
- }
- if (r == LIBUSB_SUCCESS) {
- r = linux_scan_devices(ctx);
- if (r == LIBUSB_SUCCESS)
- init_count++;
- else if (init_count == 0)
- linux_stop_event_monitor();
- } else
- usbi_err(ctx, error starting hotplug event monitor);
- usbi_mutex_static_unlock(linux_hotplug_startstop_lock);
-
- return r;
-}
-
-static void op_exit(void)
-{
- usbi_mutex_static_lock(linux_hotplug_startstop_lock);
- assert(init_count != 0);
- if (!--init_count) {
- /* tear down event handler */
- (void)linux_stop_event_monitor();
- }
- usbi_mutex_static_unlock(linux_hotplug_startstop_lock);
-}
-
-static int linux_start_event_monitor(void)
-{
-#if defined(USE_UDEV)
- return
Re: [Libusbx-devel] Major problems using libusbx on CentOS 5
Judd Taylor wrote: I've got a big (and late) project that needs to use libusb/libusbx to ingest data from a satellite demodulator. I need async capability, as well as the ability to talk via two different logical interfaces via different processes, even through they are on the same USB interface (logical interface 1 is a control channel, with an IN/OUT EP, and logical interface 2 is the data channel with an IN endpoint). I know it's retarded they are on the same USB interface, but I can handle this with forking after claim_interface() (I think). My main problem is in getting a working version of this library. I'm using CentOS5 (which can't be changed for other reasons),... CentOS 5 uses the 2.6.18 Linux kernel. It's not impossible that your troubles are due to the antiquity of your kernel, and not the interface you are using to get to it. The USB kernel support evolved rather dramatically through the 2.6 kernels. So it seems I'm stuck between a rock and a hard place here. I can't use the old version of libusb (1.0.8) because it's async stuff is racy/broken, and I can't use the new libusbx stuff since it won't get past libusb_init(). It may be sacrilege to mention it here, but it's not really all that hard to code directly to the usbfs ioctls, and that way you have complete control over your destiny. -- Tim Roberts, t...@probo.com Providenza Boekelheide, Inc. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Major problems using libusbx on CentOS 5
CentOS 5 is indeed clunky at this day and age, but I can't change it at this point, and I'm not even sure where to go from here. All of my software is RPM based, but CentOS6 is basically terrible. This is basically a multinational enterprise environment, so it's a big deal to change OS versions, and generally requires sending hard drives out to all of our customers with everything preinstalled. Yeah, not cheap. Once upon a time, the idea was that you'd be able to upgrade from like RHEL5 to RHEL6 via yum or RPM, but still waiting on that to materialize properly. In any event, I was able to get the code working (mostly, still a big or two) with libusb 1.0.9. The last version I will ever be able to use will be 1.0.15, I suppose, since that's where hotplug via netlink or libudev becomes mandatory. It's not particularly clear how to implement a single threaded async loop termination via the handle_events_completed() call, BTW. That was the main issue. It's worth noting that I had hotplug working great with CentOS5 libusb 0.1, using udev scripts. I may be able to use that same setup on this implementation. I had to ditch that because there was no async support. I'm not doing direct usbfs for this application. I have no time to start from scratch, yet again. -Judd Judd Taylor Software Engineer Orbital Systems, Ltd. 3807 Carbon Rd. Irving, TX 75038-3415 (972) 915-3669 x127 From: Tim Roberts [t...@probo.com] Sent: Monday, January 27, 2014 12:23 PM To: libusbx-devel@lists.sourceforge.net Subject: Re: [Libusbx-devel] Major problems using libusbx on CentOS 5 Judd Taylor wrote: I've got a big (and late) project that needs to use libusb/libusbx to ingest data from a satellite demodulator. I need async capability, as well as the ability to talk via two different logical interfaces via different processes, even through they are on the same USB interface (logical interface 1 is a control channel, with an IN/OUT EP, and logical interface 2 is the data channel with an IN endpoint). I know it's retarded they are on the same USB interface, but I can handle this with forking after claim_interface() (I think). My main problem is in getting a working version of this library. I'm using CentOS5 (which can't be changed for other reasons),... CentOS 5 uses the 2.6.18 Linux kernel. It's not impossible that your troubles are due to the antiquity of your kernel, and not the interface you are using to get to it. The USB kernel support evolved rather dramatically through the 2.6 kernels. So it seems I'm stuck between a rock and a hard place here. I can't use the old version of libusb (1.0.8) because it's async stuff is racy/broken, and I can't use the new libusbx stuff since it won't get past libusb_init(). It may be sacrilege to mention it here, but it's not really all that hard to code directly to the usbfs ioctls, and that way you have complete control over your destiny. -- Tim Roberts, t...@probo.commailto:t...@probo.com Providenza Boekelheide, Inc. -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Major problems using libusbx on CentOS 5
You are going to have trouble using the same interface from two different processes. Linux maintains exclusive access for a process once it has claimed an interface until it is released or the file descriptor is closed (either intentionally or from the process exiting). If you claim the interface in the parent, you'll get EBUSY in the child. As far as hotplug goes, I'm sorry to not be helpful there. Chris On Saturday, January 25, 2014, Judd Taylor jud...@orbitalsystems.com wrote: I've got a big (and late) project that needs to use libusb/libusbx to ingest data from a satellite demodulator. I need async capability, as well as the ability to talk via two different logical interfaces via different processes, even through they are on the same USB interface (logical interface 1 is a control channel, with an IN/OUT EP, and logical interface 2 is the data channel with an IN endpoint). I know it's retarded they are on the same USB interface, but I can handle this with forking after claim_interface() (I think). My main problem is in getting a working version of this library. I'm using CentOS5 (which can't be changed for other reasons), and the latest version of the libusbx simply don't work at all for me due to hotplug issues. The problem I'm getting is that it assumes I have netlink if I configure libusbx with --enable-udev=no. I have to use --enable-udev=no because while there is an early udev available, there is no way libudev.h will ever be available for this OS release. However, netlink isn't there either, so what I really need to do is to disable hotplug altogether, and I don't see any way to do this. So after fighting the above problem in 1.0.17 of libusbx, I ended up trying to move the project forward by going back releases until I found something that worked. This is libusb-1.0.8. HOWEVER, now in my latest testing, it seems I can't get the async data ingest thread to terminate properly, seemingly due to a race condition bug in that old version of libusb. (libusb_handle_events() is all that is available). So it seems I'm stuck between a rock and a hard place here. I can't use the old version of libusb (1.0.8) because it's async stuff is racy/broken, and I can't use the new libusbx stuff since it won't get past libusb_init(). Can anyone help me with this? Maybe via a patch that completely disables hotplug? PS: I'm using this through Perl, via a new XS level language extension that I'm writing. I have this working with the async callbacks (which was a nightmare in itself). Thanks, Judd Judd Taylor Software Engineer Orbital Systems, Ltd. 3807 Carbon Rd. Irving, TX 75038-3415 (972) 915-3669 x127 -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Major problems using libusbx on CentOS 5
On Sat, 25 Jan 2014, Chris Dickens wrote: You are going to have trouble using the same interface from two different processes. Linux maintains exclusive access for a process once it has claimed an interface until it is released or the file descriptor is closed (either intentionally or from the process exiting). That's not true at all. Linux maintains exclusive access for an _open file reference_ once an interface has been claimed. Not for a process. If you claim the interface in the parent, you'll get EBUSY in the child. Since open file references are shared between a parent and a child, there should be no problem. Alan Stern -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
