#15 usblib timeouts does not work correctly on solaris platforms

open
nobody
None
5
2012-12-19
2012-02-27
Martin Cerveny
No

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>

Discussion

  • Martin Cerveny
    Martin Cerveny
    2012-02-27

    multithread with blocking calls on usb

     
  • Joerg Wunsch
    Joerg Wunsch
    2012-02-27

    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.)

     
  • Martin Cerveny
    Martin Cerveny
    2012-02-27

    svn diff to 297

     
    Attachments
  • Martin Cerveny
    Martin Cerveny
    2012-02-28

    > 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>

     
  • Joerg Wunsch
    Joerg Wunsch
    2012-11-02

    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.

     
  • Joerg Wunsch
    Joerg Wunsch
    2012-12-04

    I somewhat got your point about not being able to use the libusb-1 API
    for Opensolaris (though, well, it's always a matter of someone just
    doing it -- there's an opensource libusb where Opensolaris could add
    their own support, independent of what has been inherited from Sun).

    Anyway, as I don't trust the threading to experience less problems for
    other (non-Opensolaris) users, I'd like to have this as a
    configuration option, so the actual implementation is #ifdef'ed
    appropriately. That way, people could decide at compile-time whether
    they'd like to use the thread model or multiprocess model. As the
    patch needs some additional work due to the recent error handling
    changes, please change it that way. I don't care much whether you
    also add the configuration file handling (--enable-threads or such) or
    not, I could easily do that myself. For testing, you can just edit
    the generated Makefile to add the respective -DENABLE_THREADS option
    manually.

     
  • Joerg Wunsch
    Joerg Wunsch
    2012-12-19

    I changed it a little to adopt my recent changes (use the USB
    zero-length/full-length packet mechanism to decide about when a
    message is complete, rather than pre-parsing the JTAGICEmkII data
    frames), but otherwise, committed it now. From what I can tell so
    far, it appears to work well, but please check the SVN version
    yourself.

    I also had to add some autoconf magic to detect the compiler and
    library options that are needed for pthreads.

    I did not test the Windows build yet under Cygwin, but Cygwin claims
    to be pthreads compliant, so I hope it'll do fine there.

     
  • Joerg Wunsch
    Joerg Wunsch
    2012-12-19

    Ah, cr*p. The current code completely breaks on FreeBSD. :-(
    It just passes a single message along the socket pair, and then
    jams.