On Wed, 30 Jul 2003, David Brownell wrote: > Alan Stern wrote: > > David: > > > > What is the standard way for a user process to communicate with a gadget > > driver? > > Depends entirely on how the gadget driver exposes itself, there's no > single standard way to do that. While "ether.c" handles all standard > network interface calls, plus ethtool ioctls, "gadgetfs" aims for > user mode (threaded) drivers so it exposes endpoints as normal r/w > file descriptors; most drivers won't need to use its ioctls.
Neither of those sounds just right for what I want. > > There's an ioctl() member of struct usb_gadget_ops, but it's not > > clear what it does, or how to use it, or whether it's meant to communicate > > with the gadget driver vs. the controller driver. Would this involve > > registering a char device number? How should I do it? > > The ioctl() member is for gadget-to-controller requests. If "gadgetfs" > gets an ioctl that it doesn't understand, it'll pass that call down to > the gadget driver. That doesn't use character devices, it's just a > case of "mount -t gadgetfs gadgetfs /dev/gadget". It sounds like ioctl() is for gadgetfs-to-gadget requests, not gadget-to-controller. > I suppose "ether.c" should do the same ... that's after all the standard > way to use ioctl()! And that's another example showing it doesn't need > to involve char devices. The 2.4 version of "gadgetfs" does, but that's > only because I wasn't keen on backporting "libfs" and related filesystem > changes from 2.5 ... ;) > > However, a TTY gadget would likely need lots of ioctls, as well as > character special files. > > > Using ioctl() is generally discouraged, not because it's intrinsically > bad because it so often gets abused (as in "usbfs"). Things that fit > into a read/write paradigm, like endpoint i/o, should so so. (Which > is where "usbfs" really goes strange.) Things that don't, querying > and modifying endpoint status, or similar things, shouldn't. > > Also, well designed ioctl calls shouldn't need 32-to-64 conversion, > eliminating that mess. Those 64bit cpus some folk have mentioned > wanting to use with this API should have no problems. > > > > Or would I be better off using a sysfs attribute? It would be a little > > more awkward but it would work. > > Depends what you driver is trying to do. Sysfs was explicitly not > intended to be a general purpose device driver API, so I wouldn't > use it for anything except "system management" purposes. Maybe "system management" is a good description. I'm considering writing a USB Mass Storage gadget. It will be necessary somehow to connect the gadget to an underlying storage medium, and the simplest approach seems to be the one used by the loop driver. That is, an ioctl call provides the gadget driver with a descriptor for a block device or a regular file, which the driver then uses. (Also, that means I can just copy the loop driver code :-) Doing the same thing via sysfs would come down to having a writeable attribute file where a user process could place a pathname for the device/file. It ought to work just as well, assuming that gadgets are registered in the sysfs file system. Alan Stern ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
