On Sat, 7 Sep 2013, Ludovic Rousseau wrote:

> 2013/9/7 Hans de Goede <hdego...@redhat.com>:
> > Well, alternatively we could document that libusb-compat uses atexit for 
> > cleanup,
> > and that apps using it should either not access libusb from their own 
> > atexit handlers,
> > or register their atexit handler after calling libusb_init (atexit handlers 
> > are
> > called in reverse registration order).
> 
> If we ask maintainers to modify the code of their application using
> libusb-0.1 we should just tell the to use libusb-1.0 directly.
> 
> The goal of libusb-compat is to allow "unmaintained" applications
> using the libusb-0.1 API to benefit from libusb-1.0 with no code
> change. We should not break this "contract".
> 
> So I think the best is to keep the resource leak and avoid crashes.

Slightly off the original topic but perhaps still relevant...

There are several Linux programs using libusb-0.1 that don't work with
libusb-compat.  The reason is that they perform some or all of their
I/O using the usbfs API directly, relying on libusb merely for listing
devices and opening the device files.  In particular, they get the
device's open file descriptor by abusing the interface and reading the
value directly out of the private libusb usb_dev_handle structure.

If libusb-compat were changed so that the initial parts of the
usb_dev_handle structure were the same as in libusb-0.1 -- including
the underlying file descriptor -- these programs might suddenly start
working.  (Note that doing this would require adding a function to the
libusb-1.0 API for retrieving the low-level file descriptor.)

Anybody feel like implementing this?

Alan Stern


------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Reply via email to