On Wed, Apr 18, 2007 at 11:23:23AM -0400, Alan Stern wrote: > On Tue, 17 Apr 2007, Sarah Bailey wrote: > > > On Tue, Apr 17, 2007 at 11:50:09AM -0400, Alan Stern wrote: > > > On Mon, 16 Apr 2007, Sarah Bailey wrote: > > > > > > > usbfs2 will have asynchronous support for bulk, interrupt, and > > > > isochronous transfers. It will also represent USB devices as several > > > > endpoint files in /dev that drivers can read and write to. The project > > > > page for this is http://wiki.cs.pdx.edu/usb/usbfs2.html > > > > > > Something I've meant to ask for a while... What about things that apply > > > to an entire interface or device, as opposed to a single endpoint? > > > > > > In addition to sending or cancelling URBs, usbfs allows users to: > > > > > > Issue a USB port reset to the device; > > > > > > Find out the name of the driver bound to an interface; > > > > > > Unbind a kernel driver from an interface; > > > > > > Find out the device's address and speed (although it doesn't > > > distinguish between full and high); > > > > > > Change the altsetting for an interface; > > > > > > Change the device configuration; > > > > > > Claim (bind usbfs to) an interface; > > > > > > Release (unbind usbfs from) an interface. > > > > > > Other things that might be nice but currently are not included are: > > > > > > Get the current frame number; > > > > > > Suspend the device's upstream port; > > > > > > Resume the device's upstream port. > > > > > > How will usbfs2 address all these capabilities? > > > > To be truthful, I haven't thought out that far. I suspect that some of > > the functionality (like setting the device's address, changing the > > altsetting, and changing the device configuration) could be associated > > with an ioctl on the control endpoint. It seems to make sense, since > > those commands are issued through the control endpoint. I'm not sure > > how the rest of the functionality should be represented. > > Wasn't the main point of usbfs2 to get away from using ioctls? Or was it > merely to get away from using ioctls for sending and receiving URBs?
At the very least, standard IN and OUT transfers for bulk, interrupt, and isochronous shouldn't be ioctls so that in-kernel AIO could be used. Are there other reasons that ioctls should be avoided? I've mentioned that you can't use ioctls in a bash script, but most people aren't going to use bash to write USB drivers. If the only reason to avoid ioctls is to use AIO, then the capabilites above could be implemented with an ioctl. If you're switching configurations, you would want to make sure all your previous transactions are completed and then switch configurations synchronously. You probably want to find out a device's speed shortly after you configure the device, before you start any transfers, so you don't need AIO there either. It seems sane to make both capabilities be an ioctl, but I'm open to reasons why it shouldn't be. > Perhaps usbfs2 should implement a special "device" file along with all the > endpoint files. Then these operations could be carried out by writing > some standard strings to the "device" file. That may make sense for things like claiming an interface, finding the name of the driver that has claimed an interface, and finding out the device's speed and address. Sarah
signature.asc
Description: Digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
_______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
