1<html><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.78.1"><link rel="home" href="index.html" title="The Linux-USB Host Side API"><link rel="up" href="usbfs.html" title="Chapter 7. The USB Filesystem (usbfs)"><link rel="prev" href="usbfs-bbbddd.html" title="/proc/bus/usb/BBB/DDD"><link rel="next" href="usbfs-ioctl.html" title="The ioctl() Requests"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><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="usbfs-bbbddd.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="usbfs-ioctl.html">Next</a></td></tr></table><hr></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="usbfs-lifecycle"></a>Life Cycle of User Mode Drivers</h2></div></div></div><p>Such a driver first needs to find a device file 2 for a device it knows how to handle. 3 Maybe it was told about it because a 4 <code class="filename">/sbin/hotplug</code> event handling agent 5 chose that driver to handle the new device. 6 Or maybe it's an application that scans all the 7 /proc/bus/usb device files, and ignores most devices. 8 In either case, it should <code class="function">read()</code> all 9 the descriptors from the device file, 10 and check them against what it knows how to handle. 11 It might just reject everything except a particular 12 vendor and product ID, or need a more complex policy. 13 </p><p>Never assume there will only be one such device 14 on the system at a time! 15 If your code can't handle more than one device at 16 a time, at least detect when there's more than one, and 17 have your users choose which device to use. 18 </p><p>Once your user mode driver knows what device to use, 19 it interacts with it in either of two styles. 20 The simple style is to make only control requests; some 21 devices don't need more complex interactions than those. 22 (An example might be software using vendor-specific control 23 requests for some initialization or configuration tasks, 24 with a kernel driver for the rest.) 25 </p><p>More likely, you need a more complex style driver: 26 one using non-control endpoints, reading or writing data 27 and claiming exclusive use of an interface. 28 <span class="emphasis"><em>Bulk</em></span> transfers are easiest to use, 29 but only their sibling <span class="emphasis"><em>interrupt</em></span> transfers 30 work with low speed devices. 31 Both interrupt and <span class="emphasis"><em>isochronous</em></span> transfers 32 offer service guarantees because their bandwidth is reserved. 33 Such "periodic" transfers are awkward to use through usbfs, 34 unless you're using the asynchronous calls. However, interrupt 35 transfers can also be used in a synchronous "one shot" style. 36 </p><p>Your user-mode driver should never need to worry 37 about cleaning up request state when the device is 38 disconnected, although it should close its open file 39 descriptors as soon as it starts seeing the ENODEV 40 errors. 41 </p></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="usbfs-bbbddd.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="usbfs.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="usbfs-ioctl.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> 42