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). Richard On Sun, Apr 5, 2015 at 3:34 AM Richard Flint <richard.flint at gmail.com> 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? > > I think I found some code relating to it here: > > https://java.net/projects/solaris-userland/sources/gate/show/components/libusb/wrapper/src > > Regards, > Richard > > > On Sun, Apr 5, 2015 at 3:10 AM Charles Lepple <clepple at gmail.com> wrote: > >> On Apr 4, 2015, at 9:48 PM, Richard Flint <richard.flint at gmail.com> >> 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 at gmail >> >> >> >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150405/7d5b7859/attachment-0001.html>
On Apr 4, 2015, at 10:45 PM, Richard Flint <richard.flint at gmail.com> 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 <richard.flint at gmail.com> 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/srcUnfortunately, 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 <clepple at gmail.com> wrote: > On Apr 4, 2015, at 9:48 PM, Richard Flint <richard.flint at gmail.com> 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 at gmail > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150404/a20bddd9/attachment.html>
Hi, I couldn't get openusb to make successfully but the good news is that Solaris seems to include openusb in the package repository and I have now installed it: ./usr/lib/libopenusb.so.0.0.1 Any idea how i can get NUT to build against this libopenusb which has been installed by Solaris? Regards, Richard On Sun, Apr 5, 2015 at 4:20 AM Charles Lepple <clepple at gmail.com> wrote:> On Apr 4, 2015, at 10:45 PM, Richard Flint <richard.flint at gmail.com> > 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 <richard.flint at gmail.com> > 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 <clepple at gmail.com> wrote: >> >>> On Apr 4, 2015, at 9:48 PM, Richard Flint <richard.flint at gmail.com> >>> 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 at gmail >>> >>> >>> >>>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150405/e3ea1282/attachment-0001.html>