> >>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. > Yes that sounds about right :)
> 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. > Well actually I was using in user-mode-linux the entire standard usb core on top of the hosts usbdevfs this is not actually too bad as the usb driver in uml submits its urb and the uml-hcd then sends a urb out to the matching /proc/bus/usb/00X/XXX entry the completeion for the host-side urb in uml-hcd then posts a completeion up to the user-side urb. The uml-hcd has to track the changes to /proc/bus/usb/XXX for plug/unplug, and as part of tracking, "(a)" occurs, "(b)" & "(c)" are just by forwarding urbs, and for (d) only hubs are simulated so the host can manage them leaveing the rest to the linux usb layer anyway. > 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. > Which async API? the uml-hcd basicly just forwards urbs back and forth using the ioctls on /proc/bus/usb/XXX[/XXX]* > > > 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.) > As I recall it simulates Interrupt with a bulk transfer on the host and runs it like a Interrupt transfer at the uml-hcd level > > 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". > Which state synchronization, the hub stuff is messy as there are races over which layer gets the update first. If I get it working well enough it might be worthwhile to see about having some way for hub.c to report what happened, rather than the racy inference. > - 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
