On Wed, Oct 31, 2012 at 7:41 AM, Sven Köhler <sven.koeh...@gmail.com> wrote:
> Now on OS X, we need to talk to USB devices. A driver for these devices > might already be installed. So that would probably need to be detached. > Furthermore, the program that uses libusb is not running with elevated > rights. it must be possible for a normal user to talk to these devices > without having any special privileges. I do not see any problems with privileges under either Mac OS X or Windows. On the other hand, driver detaching is a big problem for Windows and even more troublesome under Mac OS X. > Now on Linux, most of that is straight forward. In order to grant users > access to certain devices, users are added to certain group and the > matching udev rules are create. What would be the equivalent of that on > OS X? No need to do anything with regard to this point. > Now detaching an already active driver is the next problem. On Linux, > libusb_detach_kernel_driver is implement. Well, it suffers from a pretty > annoying issue: libusb can detach libusb. Or as far as I understand: if > libusb detaches a driver, it puts some kind of "general driver" in > charge of the device. And if another process calls > libusb_detach_kernel_driver, then this general driver is detached which > kills the connection to the device for the process which is already > talking to that device. And of course first getting the name of the > attached driver, and then detaching it depending on the name gives birth > to a race condition. > When I mentioned that issue, it was thrown at me, that I should perform > external synchronization. You know, like with serial devices, which you > don't open unless you have locked a certain lock file. Now what's the > default location of the lock files for USB devices? > (Yes, I know that it doesn't exist. It's sarcasm.) > > Does a similar issue exist for OS X? I mean if detaching a driver is > possible at all? libusb_detach_kernel_driver is Linux only. It is not supported under Windows or Mac OS X or BSDs. You can use a codeless kext to prevent the default driver from attaching to the device. Of course you will lose the function associated with the original driver, > > Now device I'm talking about is the Lego NXT. Most of the time, it's > some not very specific USB device that doesn't implement any special > profile. But sometimes (in firmware update mode), it claims to be a > cdc_acm device. I believe the driver by Lego handles the device in both > modes. For the generic class, you do not need to do anything. For CDC-ACM, then it is better you do not use libusbx and just use the serial API for that function (firmware update). -- Xiaofan ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
