David Brownell said: > Charles Lepple wrote: [...] >> * cross-platform libusb support: [...] > In general, it's worth avoiding multiple code paths. If "libusb" > will do the vendor control messages, just use it everywhere; it'll be > simpler to maintain/debug that way.
I am reminded of an Edsger Dijkstra quote: "Computing's central challenge, viz. 'How not to make a mess of it', has /not/ been met." Right after making the LIBUSB branch, I realized the problem: sending control messages isn't the problem, opening the proper device is. IMHO, libusb does an excellent job of abstracting USB devices, but this abstraction makes it difficult for fxload to handle its original job of downloading firmware to a specific device (and not just any device that matches a given VID/PID). Without breaking encapsulation, the only way for a libusb-based fxload to honor the requested device path is to search all of the devices found by libusb and identify where bus->filename and dev->filename match. This doesn't solve my original problem (the motivation for considering libusb in the first place), which was to not have two separate programs for loading EZ-USB chips under Linux and (in my case) Mac OS X. Under OS X, since fxload wouldn't be called by hotplug scripts, I would want to match by VID/PID anyway, but that doesn't warrant the aforementioned kludge for Linux. I'm going to ponder this one some more, but I'm leaning towards not trying to merge the libusb-enabled version back into the main branch. Suggestions welcome. -- Charles Lepple <[EMAIL PROTECTED]> http://www.ghz.cc/charles/ ------------------------------------------------------- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
