From: Alan S. <st...@ro...> - 2013-09-07 15:36:11
|
On Sat, 7 Sep 2013, Ludovic Rousseau wrote: > 2013/9/7 Hans de Goede <hde...@re...>: > > 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 |