<?xml version="1.0" encoding="ANSI_X3.4-1968" standalone="no"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=ANSI_X3.4-1968" /><title>Life Cycle of User Mode Drivers</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /><link rel="home" href="index.html" title="The Linux-USB Host Side API" /><link rel="up" href="ch07.html" title="Chapter 7. The USB Filesystem (usbfs)" /><link rel="prev" href="ch07s04.html" title="/proc/bus/usb/BBB/DDD" /><link rel="next" href="ch07s06.html" title="The ioctl() Requests" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Life Cycle of User Mode Drivers</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch07s04.html">Prev</a> </td><th width="60%" align="center">Chapter 7. The USB Filesystem (usbfs)</th><td width="20%" align="right"> <a accesskey="n" href="ch07s06.html">Next</a></td></tr></table><hr /></div><div class="sect1" title="Life Cycle of User Mode Drivers"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="usbfs-lifecycle"></a>Life Cycle of User Mode Drivers</h2></div></div></div><p>Such a driver first needs to find a device file for a device it knows how to handle. Maybe it was told about it because a <code class="filename">/sbin/hotplug</code> event handling agent chose that driver to handle the new device. Or maybe it's an application that scans all the /proc/bus/usb device files, and ignores most devices. In either case, it should <code class="function">read()</code> all the descriptors from the device file, and check them against what it knows how to handle. It might just reject everything except a particular vendor and product ID, or need a more complex policy. </p><p>Never assume there will only be one such device on the system at a time! If your code can't handle more than one device at a time, at least detect when there's more than one, and have your users choose which device to use. </p><p>Once your user mode driver knows what device to use, it interacts with it in either of two styles. The simple style is to make only control requests; some devices don't need more complex interactions than those. (An example might be software using vendor-specific control requests for some initialization or configuration tasks, with a kernel driver for the rest.) </p><p>More likely, you need a more complex style driver: one using non-control endpoints, reading or writing data and claiming exclusive use of an interface. <span class="emphasis"><em>Bulk</em></span> transfers are easiest to use, but only their sibling <span class="emphasis"><em>interrupt</em></span> transfers work with low speed devices. Both interrupt and <span class="emphasis"><em>isochronous</em></span> transfers offer service guarantees because their bandwidth is reserved. Such "periodic" transfers are awkward to use through usbfs, unless you're using the asynchronous calls. However, interrupt transfers can also be used in a synchronous "one shot" style. </p><p>Your user-mode driver should never need to worry about cleaning up request state when the device is disconnected, although it should close its open file descriptors as soon as it starts seeing the ENODEV errors. </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch07s04.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch07.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch07s06.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">/proc/bus/usb/BBB/DDD </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> The ioctl() Requests</td></tr></table></div></body></html>
