<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 24, 2014 at 7:46 AM, Charles Lepple <span dir="ltr"><<a href="mailto:clepple@gmail.com" target="_blank">clepple@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Apr 19, 2014, at 1:23 AM, Stephen J. Butler wrote:<br></div><div class="">
> 2. With my hardware and kernel, usbhid-ups wouldn't run more than 10 minutes before exiting with a fatal error. This seems to be related to holding usb_claim_interface() the entire life of the program. I've refactored claim_interface/release_interface calls to be around only when work is being done. Now usbhid-ups has run for 24+ hours without issue.<br>

<br>
</div>Given how long we have been running with code that claims the interface at driver startup, I am a wary about changing this behavior. Have you had a chance to raise this with the Linux USB folks? I don't see any reason why claiming the interface for an indefinite amount of time shouldn't be expected to work.<br>
</blockquote><div><br></div><div>No, I haven't. I'm not entirely convinced it's the kernel or libusb causing my problems. I half believe it could be some other userland program running. For example, I had no idea I had dbus running upower before debugging this issue.</div>
<div><br></div><div>I didn't go as far as doing a stap on it. The more I thought of it, the more I decided that usbhid-ups should allow other programs on the system to claim the device if they want.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

We will, of course, need to test this on other models of UPS which are supported by usbhid-ups.<br>
<br>
Assuming for a moment that the fatal error is due to a regression in the kernel, are there other general advantages to only claiming when needed?</blockquote><div><br></div><div>I noticed when hacking around in libusb.c that there was a comment in libusb_close() about not calling usb_release_interface() because it hangs. That doesn't seem right to me, and I couldn't find any other libusb examples that advocated claiming the device the lifetime of the program. I wonder if it wasn't an early symptom of this.</div>
<div><br></div><div>As far as testing, it does seem like a risky change.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would be a lot more excited about retesting all of this if we could somehow leverage udev (or equivalent, on non-Linux) to make this event-driven. Then, the individual drivers don't have to deal with reconnection, and when the UPS disappears for any reason, the driver simply exits. The problem for libusb-0.1 is that I don't know of a clean way to pass a udev device specification to usb_open(). (Insert rant about most USB devices not having unique serial numbers in their device descriptors.)<br>

<br>
Thoughts? Has anyone implemented a similar udev-to-application handoff in libusb-1.x?</blockquote><div></div></div><br></div><div class="gmail_extra">Nope, no udev experience. And certainly not on other platforms.</div></div>