> But I *do* mind if I have to > > - make my own lib for queueing of control messages. > - code around usbdefvs, which is issuing control messages at probe() time.
Are these not the same problem? You probably know that some UHCI patches for this have been posted recently. They need some work yet, aren't merged (into 2.5). > - work around INT OUT with non-constant message length (o what a mess!). Patches for this ... also not merged. This gets fixed when "automagic resubmit" goes away. It'll also get rid of a bunch of squirrely places for bugs (including HCD differences) to hide. > - acount for the differences of three HCD drivers. They're getting a LOT closer now. But I suspect you'll always need to accept some differences in how specific faults get reported, since the hardware really is different. Disconnects don't look the same, for one example that already needs far too much driver testing. Make sure you report any such remaining differences in the 2.5 kernels, preferably with some test code (maybe added drivers/usb/misc/usbtest.c) that shows it happening. > I would like very much an API where I have to open() an endpoint before using > it, and closing it afterwards. And open() should lock out all other > libs/drivers for this endpoint! Effectively you have this: claiming interfaces is opening, and disconnecting from them is releasing them. The rule is that only the driver that claims an interface is allowed to use its endpoints. There's no way to lock out other drivers in the kernel though, if they don't follow the rules. That's the drawback of a shared address space, but it's one that's easily fixed by shooting the ill-mannered driver (with a patch, not the air force :). - Dave ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
