Bugs item #3495122, was opened at 2012-02-27 14:00 Message generated for change (Comment added) made by joerg_wunsch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=425407&aid=3495122&group_id=39505
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin Cerveny (mcerveny) Assigned to: Nobody/Anonymous (nobody) Summary: usblib timeouts does not work correctly on solaris platforms Initial Comment: Hello. There is problem with usb_bulk_read/usb_bulk_write timeouts in usblib( 0.1.8) on opensolaris/solaris platforms (probably on all <1.0 usblib versions). I reprogrammed jtag2usb.cc to use thread model (instead of multiprocess) for read and write threads and use blocking calls (timeout = 0). M.C> ---------------------------------------------------------------------- >Comment By: Joerg Wunsch (joerg_wunsch) Date: 2012-11-02 15:38 Message: After the next release, I'm all open if someone wants to rewrite the USB stuff. In theory, with the libusb 1.0 API, I think we don't need either threads or multiprocessing (or condvars) at all. The current "USB daemon" approach has only been implemented in order to be able to poll() (or select(), doesn't matter) for both, USB as well as GDB communication in the master process. However, since the libusb 0.1 API doesn't provide a normal Unix filedescriptor, the "USB daemon" served as a helper process for libusb, providing a pollable pipe descriptor to the master process. Anyway, I don't want to lose Cygwin portability with all this. That's probably the only part that has to be verified before switching to something completely different. ---------------------------------------------------------------------- Comment By: Martin Cerveny (mcerveny) Date: 2012-02-27 16:09 Message: > Also, I'm not sure I'd like to have the threads version as a general > version, at least not until it's proven it will work well on all the > existing platforms (including Cygwin!). Thus, I'd prefer it the > threads code were #ifdef'ed, with either a manual or an automatic > detection (by probing for Solaris) in the configure.ac script. Threads is first step, communication rewrite should be nice (replace pipe with some condvars...) :-). > Finally, it seems on Solaris, no further flags to the compiler/linker > are needed to tell them to build a threaded executable. Other systems > do require additional options here (like -pthread on the entire > toolchain, or just -lpthread on the linker commandline), so we have to > add autoconf magic for that. man page says "cc -mt -lpthread ..." but works without it (maybe some gcc/libgcc magic). > Given the amount of work required for all that, isn't it perhaps > better to implement an alternative, libusb-1 based version? As > libusb-1 uses a pollable descriptor (I've heard so, I hope it really > does) There is the "Oracle" problem. Oracle closed OpenSolaris and ignoring to use *Solaris on workstation (eg, usb rich device), The usblib will not be updated to 1.x :-( (actual version is 0.1.8). There are other derived distributions (Illumos/OpenIndiana) that may update the usblib. The Solaris usblib is wrapper to Solaris usba/ugen architecture that may be unwrapable to usblib>1.0. I do not say that patch must be integrated. I have sometimes problem with communication with avr-gdb/jtagice. I suppose that is due to desynchronization between reader-writer threads :-( M.C> ---------------------------------------------------------------------- Comment By: Joerg Wunsch (joerg_wunsch) Date: 2012-02-27 14:22 Message: Sorry, the source tree *heavily* changed lately, since I rewrote the entire error handling to use C++ exceptions rather than the crocky mix between return codes, trying to call exit(), or just ignoring the error that used to be there before. Consequently, your patch no longer applies. :-( Could you rewrite it against the SVN version? If I tried adapting your patch, there's a high risk I might break something, and I don't have a Solaris machine around wich is equipped with USB to really test it. Also, I'm not sure I'd like to have the threads version as a general version, at least not until it's proven it will work well on all the existing platforms (including Cygwin!). Thus, I'd prefer it the threads code were #ifdef'ed, with either a manual or an automatic detection (by probing for Solaris) in the configure.ac script. Finally, it seems on Solaris, no further flags to the compiler/linker are needed to tell them to build a threaded executable. Other systems do require additional options here (like -pthread on the entire toolchain, or just -lpthread on the linker commandline), so we have to add autoconf magic for that. Given the amount of work required for all that, isn't it perhaps better to implement an alternative, libusb-1 based version? As libusb-1 uses a pollable descriptor (I've heard so, I hope it really does), there's no longer a need for the multiprocessing or multithreading approach at all. That approach has only been introduced to be able to poll on both, the ICE connection over USB as well as the GDB socket descriptor at the same time, which libusb-0.1 doesn't allow for. (Again, the libusb-1 based implementation should be #ifdef'ed, so platforms not offering a port of libusb-1 could continue to use the existing approach.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=425407&aid=3495122&group_id=39505 ------------------------------------------------------------------------------ LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d _______________________________________________ avarice-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/avarice-user
