On Wed, Apr 18, 2007 at 11:54:09AM -0400, Mike Panetta wrote: > Alan Stern wrote: > >On Tue, 17 Apr 2007, Sarah Bailey wrote: > > > >> > >> 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? > > > >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. > > > >Alan Stern > > > > Just out of curiosity, why do we want to get rid of ioctl calls? They > aren't all that bad, are they? With an ioctl call its obvious you want > to write some structured data of some sort to a device to control it, > with read/write its not immediately obvious that you want to write > anything more then a string of bytes. Maybe I am just being pedantic, > either way I am curious as to why the change is proposed.
A few ioctls are not bad. However, with usbfs, you have to do everything with ioctls. Most of the operations, like transmitting data to an endpoint, would have been better represented by read/write system calls. In hindsight, the overuse of ioctls was probably an indication that the system wasn't designed well. usbfs represents a USB device as a device file, and usbfs2 represents it as several endpoint files. > I probably would be happy with a simple udev script that names device > entries based on geographical connection to the bus with links to the > bus/address device naming scheme usbfs2 does something similar to that. When a device is plugged in, it creates an entry in /dev with the naming scheme usbdev<bus number>.<device number>_epXX It sounds like that's what you want. >, and I can already have that with some > simple modifications to libusb so that it recognizes the device tree and > a custom udev script I believe. Actually I really don't think I care > how its done just so long as there is a clean interface to it (via > libusb or whatever) I hope that libusb can be rewritten to use usbfs2, but you can use usbfs2 by itself to write userspace Linux USB drivers. 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
