Am Montag, 9. Januar 2006 09:02 schrieb Eric Dorland: > Aurelian, > > Could you comment as to whether this is libusb breakage or not?
the bug was closed. I still think it was in libusb, but can't find anything in the source. as an alternative the kernel might have been patched with some crap and thus malfunctioned. but as noone can reproduce the problem, and I didn't get any new bug reports either, we can keep it closed. if you can reproduce the problem however (run "strace openct-control init", if ifdhandler is run with "/proc/bus/usb/X/Y" instead of "/proc/bus/usb/XXX/YYY" you found the problem), please let me know. the claim that it was the kernel fault is not true, in as far as the vanilla kernel has been working or me and many other people very well and doesn't cause any problem. the claim that we need to handle two namespaces is wrong: openct uses and depends on usbfs mounted on /proc/bus/usb and I haven't heard that anyone will obsolete that interface. till today kernel<->user space api has been very stable, so I hope usb will be no exception, so I hope we can count on the /proc/bus/usb/XXX/YYY namespace for a several more years, i.e. wait till the new namespace has been settled down (I guess they changed it at least once times in the meantime), and has been deployed to all current systems, so we can realy count on it being available. the claim that we could use usb_open() is simply not true: libusb has no select() / poll() interface as far as I know. neither does it understand the strings given to us by the linux kernel, hotplug, udev, hald, freebsd usbd or devd or the similar mechanisms on other operating systems, I'd be happy to use libusb and dump our native code. but so far it looks like it would be a lot easier to dump libusb and write everything ourself, than to use libusb. requests to add the features we need to libusb have been unsuccessful. as far as I know the design principle is to only offer what all plattforms offer, and that is a very limited subset, mostly because of apple mac os X and its very, very different api. Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
