On Apr 4, 2015, at 10:45 PM, Richard Flint <[email protected]> wrote:
> Hi, > > Apologies for the many replies. I have found this documentation: > http://www.lehman.cuny.edu/cgi-bin/man-cgi?ugen+7 > > (I am using the ugen driver). Right, AFAIK ugen is the kernel driver that libusb and openusb talk to (/dev/usb/*). Updated diagram: upsc --- upsd --- nutdrv_qx --- libusb -+- ugen driver --- Solaris kernel --- UPS > Richard > > On Sun, Apr 5, 2015 at 3:34 AM Richard Flint <[email protected]> wrote: > Hi, > > I have to admit this sounds like it could screw up the system if not done > right - particularly because the solaris packaging system is unlikely to > allow me to remove the libusb package if many things are dependent on it. > > Are there any other options - e.g. doing something with the libusb that ships > with solaris - are we sure it doesn't support timeouts? Not entirely certain that we can't do more with the system libusb. NUT passes timeouts in milliseconds. If the NUT driver blocks for more than 5 seconds on the read (I see both 1000 and 5000 ms in various places in the code), then libusb isn't honoring that timeout. Without documentation or the source code, I wouldn't know what else is needed to make the timeouts work. It might be possible to do the following: • install openusb into an alternate directory (e.g. $HOME/local) • set PKG_CONFIG_PATH to anything that doesn't contain the system libusb.pc • put $HOME/local/bin (or wherever openusb-config gets installed) at the front of the $PATH, and symlink openusb-config to libusb-config • reconfigure NUT By installing into $HOME/local (not as root), you can be certain you are not overwriting the system libusb. Unfortunately, openusb doesn't have a *.pc file, otherwise the installation process would be a lot simpler. > I think I found some code relating to it here: > https://java.net/projects/solaris-userland/sources/gate/show/components/libusb/wrapper/src Unfortunately, that wrapper code is calling into a platform-specific library which doesn't seem to be posted there. (The purpose seems to be abstracting away the differences between Solaris and Sun Ray systems.) Timeouts are passed straight through, but that just moves the question down a layer into that Solaris-specific libusb plugin. > > Regards, > Richard > > > On Sun, Apr 5, 2015 at 3:10 AM Charles Lepple <[email protected]> wrote: > On Apr 4, 2015, at 9:48 PM, Richard Flint <[email protected]> wrote: > >> Again, apologies for my ignorance - are you suggesting that if the NUT >> application was built against openusb this would probably be fixed? > > Yes, that is my current theory. It's a little complicated in practice - > openusb has a different API than libusb-0.1.x, but it supposedly includes a > compatibility layer. > > If openusb works, I would not expect it to wait for more than 1 or 5 seconds > when reading the reply. > >> If so I'm happy to give this a try - any idea how can I tell NUT to build >> against openusb instead of libusb? > > Not sure exactly, but to be safe, I'd make an extra backup of wherever libusb > is installed - my concern is that other things might be using libusb, and > openusb could interfere. Ideally, openusb is a strict superset of libusb, but > I haven't used it myself. > > openusb does seem to use the same library name as libusb, so if libusb was > installed by a package, you might want to uninstall libusb first to avoid > conflicts. > > NUT uses either the generic pkg-config tool or a libusb-config binary to find > the USB library. openusb seems to install an openusb-config file which could > be symlinked to libusb-config in /usr/local/bin (once the original libusb > package is out of the way). At that point, you can re-run the NUT ./configure > script, and it should list the openusb version number (1.1.11?) instead of > 0.1.7. > > -- > Charles Lepple > clepple@gmail > > >
_______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
