On Sunday 21 January 2007 2:42 pm, Sarah Bailey, Josh Triplett wrote:
>
> After thinking about the problem for a while, we came up with a possible
> solution for fitting this into the read/write syscalls: userspace should
> first write the setup packet to the control endpoint, before performing
> the read or write of the corresponding data. The endpoint device code
> can stash the setup packet in the file's private pointer, along with the
> ep_device and any other data like transfer flags.
>
> While multiple open files of the same endpoint device share the same
> ep_device, they will each have their own setup packet.
At first glance that seems OK.
Notice how that's _necessarily_ asymmetric with respect to the peripheral
side interface of gadgetfs. The host side is the master; the peripheral
side is the slave. Two very different control models. Gadgetfs exposes
an event model to userspace, as the primary "reactive control" model that
drivers need to handle. A host side "usbfs2" doesn't need to be anywhere
near as "reactive" as that.
But that does raise the question of what to do with state management.
There are at least two types of state management on the host side:
* Config change (SET_CONFIGURATION, SET_INTERFACE) ... which should
maybe not be permitted using the generic control endpoint support;
* Connect, disconnect, reset, suspend, resume, wakeup ... which
I'm grouping together here more out of laziness than correctness,
since it's possible they each need distinct approaches. And at
least some of those kinds of state management might be best as
event notifications to the driver.
Also, as I noted separately, I suspect that endpoint halt management
might likewise be best handled outside of a generic "control endpoint"
mechanism (as with config changes).
> In addition to allowing multiple simultaneous users of control
> endpoints, this semantic still supports using control endpoint devices
> in shell scripts. For example, exec 3<> /dev/usbdev2.6_ep00 and then
> use 3< and 3> in your commands to read and write the endpoint (such as
> dd).
I certainly support the notion of shell scripts being able to drive
USB devices ... although I suspect that'd be more along the lines of
a "sufficiency proof" than something that'd get much use. The key
points appear (to me!) to be avoiding ioctl() as much as possible,
so programming environments that are "simple" (like a shell) or which
otherwise can't easily access ioctl definitions from C headers (LISP,
TCL, Perl, Ruby, etc) can still usefully interact with USB devices.
Or were you actually planning to write device drivers in ASH? :)
- Dave
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
