James McMechan wrote: >>Could you tell me a bit what you think a UML HCD would do? I've yet to >>fire upUML. I was under the impression that it wasn't really able to >>debug real device drivers -- yet. > > Well that depends on what you mean by a real device driver :) what it > currently does is open the files in /proc/bus/usb/XXX and then simulates a > hub, as the host usb layer needs to talk to the real hub devices.
Having done something similar in Java, I'll have to say I don't think that "usbfs" is really all that well suited for the task. It can be done, but there's a certain aura of "stand on your head and whistle 'dixie'" involved. Doing such things well needs an improved user mode API to Linux-USB, I believe. I think the basic issue is that if you're trying to offer a device driver framework through usbfs, you're forced to (a) recreate the USB device tree, unless you somehow hide hubs, (b) including the distinction between devices and interfaces, (c) while multiplexing N concurrent event streams through each usbfs file handle [yeech], and (d) tracking changes to all the above which happen as devices plug/unplug, configurations change [luckily rare], altsettings change [common with iso], ... and more. The reason usbfs can be useful is that most user mode drivers only need to see a few specific non-hub devices, so (a) can be simplified; work with single-interface devices, so they can punt (b); work with control/bulk-only half-duplex device protocols, so they don't trip over (c) until they need to collect status through interrupt endpoints at the same time they're doing synchronous I/O through c/b; and punt complex device models to kernel drivers. If UML is using the async usbfs APIs to get past (c), that still leaves the other issues. > It takes the data from /proc/bus/usb and then registers those devices in the > UML usb layer, sounds simple doesn't it, for testing I usually use a USB > smart card reader and the pcscd daemon which shows the reader OS and ATR > from the smartcard I think most of those devices fit into the limited category of (c), using C/B transport (or even bulk-only), not CBI. Likewise printers and scanners. (Plus still image cameras and MP3 players that don't use usb-storage.) > Recently I have been trying to fix the building USB on 2.5 stuff. > > My thought on stuff this might help with: ending up with a something like > iSCSI (iUSB?) to allow remote use of USB devices, with UML this can be done > trivially but it can also be done in userspace normally with a minimal > amount of effort. Not so minimal -- I've prototyped it, and the (d) state synchronization is problematic. For one thing, it's got to be _inferred_ from usbfs, including some plausible event ordering. (I'm fairly sure that any plausible ordering will be OK, but at least the parent/child sequencing needs to be reasonable.) For another, those (d) issues aren't always handled cleanly in the kernel: there's a fair amount of "just change the endpoint config and expect the HCDs to recover". - 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
