Hi Dave, > * How about usermode APIs? "libusb" and "usb(dev)fs" are > essentially what C programmers use, and there's some > notion of portability to non-Linux systems. I'm not > sure it's realistic to try helping BSD implement usbfs2. > Also, a C-only framework is undesirable. (Minimizing > use of ioctl will be a big win for non-C programming.)
I guess libusb could get a new implementation (wrapper) that maps its methods onto operations on usbfs2 and sysfs. That would maintain backwards compatibility. On the other hand, I guess usbfs won't be going away any time soon, so it's not a big deal. > * How about UI/commandline tools? If users can't browse > usb devices easily with "usbfs2" I have a hard time > imagining everyone converting. "usbutils" may well need > replacement. Maybe sysfs is what should be browsed. Yes, sysfs. > * How should this relate to "udev"? One implementation > strategy would make "usbfs2" endpoint files be regular > character devices. There are other strategies too, > including not coupling them at all. I thought of using regular character devices - and while it doesn't feel as elegant as using a special file system, it does have the advantage of being a simple mechanism that everyone understands. > * How should this relate to "sysfs"? I kind of like the > idea of having the "usbfs2" directory structure match > sysfs. If the two are linked effectively, then all > of the /proc/bus/usb/devices functionality should be > coming from sysfs. (Except, see the next point.) sysfs should be used for control - selecting configurations, and binding of drivers to devices. > * How should non-current configurations be exposed? > Right now they're not visible through sysfs in the > way they're visible in /proc/bus/usb/devices. It may > be just fine to say that usermode code must issue > the control requests itself. And there's also the problem of race conditions. Imagine that you select a new configuration via sysfs (which maybe triggers the creation of endpoint files for that configuration), and then open an endpoint file. What's to stop someone else changing the configuration between you setting it and opening the endpoint? Also, should it be possible to lock-down a configuration so no-one else can change it? Maybe all configurations should be exposed simultaneously (or at least all endpoints files should always be visible). Then you can grab the endpoint-in-a-certain-configuration file without any problems. But then you have the problem of endpoints in different configurations being manipulated at the same time... I guess the right thing to do is to have only files for the current configuration be visible, but with a naming scheme that makes it impossible to open an endpoint for a different configuration to the one you thought you were opening. > * How should interfaces be presented? My initial guess > is as directory, with files for each endpoint in the > active altsetting and likely one for ep0 ... at least, > interfaces claimed by "usbfs2" could look that way. A directory structure: configuration_name/interface_name/endpoint with endpoint being a file. Only the directory for the current configuration would be visible at any given time (of course if you were wandering around inside configuration_name when the configuration was changed, you will still see that directory until you exit due to reference counting). > If they're claimed by some kernel driver, or aren't > claimed at all, I'm not sure if they should appear. They could appear, but be -EBUSY when you try to open an endpoint. But I think I agree with you here - you should only see interfaces that are available for use. > (Other than in sysfs.) We should still have the > ability to let usermode code control what kernel driver > is bound to which interface. Choosing which driver controls a device goes beyond USB - and should be done somehow via sysfs I suppose. > * How much should "usbfs2" really be part of "usbcore"? > I think some per-device capabilities (fetching config > descriptors, for one) should exist even when no user > mode driver is talking to any device interface. > > Couldn't we make "usbfs2" just probe()/disconnect() > like any other interface's driver ... and not have > interfaces accessible otherwise? No auto-claim. > Trivial if sysfs binding info becomes writable (the > symlink syscall could do that), vs. just readonly. usbfs2's probe method would need to be called after everyone else's, but that's still an improvement. Of course user-space programs may want exclusive access to an interface, but I guess USB interface claiming shouldn't be used for that - they could obtain exclusivity by using some kind of file-locking method on the endpoint files. > * How should devices be presented? My initial guess is > as a directory, with subdirectories for each interface > and one file for ep0 access. (Unconfigured devices > will have no interfaces, so no per-interface ep0 file.) > Plus of course the sysfs info. I think the interfaces should be in a directory representing the configuration (only one of these, with a name depending on which configuration it is), so that you can always be sure that you are dealing with an endpoint etc in the configuration you want. > * How should buses be presented? Maybe not at all, other > than by the root hub having a different type of name. > > * How will USB OTG support affect this? Hard to say just now, > but it'll be good to keep that in mind. All the best, Duncan. ------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
