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.
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".
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.
- Dave
------------------------------------------------------- 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
