Hi,
I recently had the need to compile a 32-bit version of the libusbx library
(v1.0.17) on a 64-bit RHEL 6.5 system (Linux Kernel v2.6.32). What I found
was that libusbx does not function properly when auto_detach_kernel_driver
is set to be used. The error-handling code in
detach_kernel_driver_and_claim() expects the ioctl to fail with ENOTTY when
the ioctl is unsupported, and this indeed does happen from 64-bit
userspace, but 32-bit userspace gets EINVAL.
Prior to the addition of the disconnect-claim feature for Linux, this
failure would not have occurred.
I tested this on a 64-bit Fedora 19 installation and did not see the same
issue, presumably because that kernel supports the ioctl and has the
necessary translation from 32-bit userspace.
One additional note is that not using the auto_detach_kernel_driver feature
is not sufficient to prevent failure. Even if a user does not use this
feature, the code in op_reset_device() uses the
detach_kernel_driver_and_claim() function to re-claim any claimed
interfaces following the device reset.
Is it sufficient to check for EINVAL in the same manner as ENOTTY and fall
back to the traditional claim_interface() call? Was there a reason that
EINVAL was specifically handled in the error-handling code of
detach_kernel_driver_and_claim(), and how might a user interpret a
claim_interface() error of LIBUSB_ERROR_INVALID_PARAM?
Regards,
Chris
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
