On Tuesday, December 07, 2010 14:19:59 Charles Lepple wrote: > On Dec 7, 2010, at 7:10 AM, Arjen de Korte wrote: > > Citeren Michal Hlavinka <[email protected]>: > >> I've been asked to find out some answers from libusb maintainer, so > >> I'm > >> forwarding them: > >> > >> - Why nut uses legacy libusb-0.1 api and not libusb 1.0 ? > > > > Well, mostly because at the time we started adding USB support to > > NUT, libusb-0.1 was all there is. > > Also, there is a little more static friction to overcome if we switch > to libusb-1.0 - in order to keep configure-time complexity down, we > would want to switch *all* of the drivers to libusb-1.0 (since not all > of the USB-based drivers are served by the common code that usbhid-ups > uses). The real trick there is runtime testing of all of the drivers. > > If you are trying to eliminate direct dependencies on the old > libusb-0.1 package, there is always the libusb-0.1-compat package. I > believe that FreeBSD 8+ has incorporated that into their libusb-1.0 > API for the new USB stack, and aside from some changes in our > configuration scripts, it seems to work well at runtime.
AFAIK libusb maintainer works on libusb-compat and wanted to know whether it'is be sufficient to place libusb to /lib or libusb-compat is needed in /lib too (for nut shutdown and /usr/ unmounted) > NUT as a whole doesn't reap many of the benefits of libusb-1.0 since > the NUT architecture uses a single thread and process to interact with > the hardware. A more integrated system like UPower might be better > served by the asynchronous calls in 1.0. thanks for answers _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
