?? c-iosys9.html
字號:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html><head><link rel="STYLESHEET" type="text/css" href="wrs.css"><title> I/O System </title></head><body bgcolor="FFFFFF"><p class="navbar" align="right"><a href="index.html"><img border="0" alt="[Contents]" src="icons/contents.gif"></a><a href="GuideIX.html"><img border="0" alt="[Index]" src="icons/index.gif"></a><a href="c-iosys.html"><img border="0" alt="[Top]" src="icons/top.gif"></a><a href="c-iosys8.html"><img border="0" alt="[Prev]" src="icons/prev.gif"></a><a href="c-filesys.html"><img border="0" alt="[Next]" src="icons/next.gif"></a></p><font face="Helvetica, sans-serif" class="sans"><h3 class="H2"><i><a name="85069">3.9 Internal Structure</a></i></h3></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="85070"> </a>The VxWorks I/O system is different from most in the way the work of performing user I/O requests is apportioned between the device-independent I/O system and the device drivers themselves.</p><dd><p class="Body"><a name="85072"> </a>In many systems, the device driver supplies a few routines to perform low-level I/O functions such as inputting or outputting a sequence of bytes to character-oriented devices. The higher-level protocols, such as communications protocols on character-oriented devices, are implemented in the device-independent part of the I/O system. The user requests are heavily processed by the I/O system before the driver routines get control.</p><dd><p class="Body"><a name="85073"> </a>While this approach is designed to make it easy to implement drivers and to ensure that devices behave as much alike as possible, it has several drawbacks. The driver writer is often seriously hampered in implementing alternative protocols that are not provided by the existing I/O system. In a real-time system, it is sometimes desirable to bypass the standard protocols altogether for certain devices where throughput is critical, or where the device does not fit the standard model.</p><dd><p class="Body"><a name="85074"> </a>In the VxWorks I/O system, minimal processing is done on user I/O requests before control is given to the device driver. Instead, the VxWorks I/O system acts as a switch to route user requests to appropriate driver-supplied routines. Each driver can then process the raw user requests as appropriate to its devices. In addition, however, several high-level subroutine libraries are available to driver writers that implement standard protocols for both character- and block-oriented devices. Thus the VxWorks I/O system gives you the best of both worlds: while it is easy to write a standard driver for most devices with only a few pages of device-specific code, driver writers are free to execute the user requests in nonstandard ways where appropriate.</p><dd><p class="Body"><a name="85076"> </a>There are two fundamental types of device: <i class="term">block</i> and <i class="term">character</i> (or <i class="term">non-block</i>; see <a href="c-iosys9.html#93984">Figure 3-8</a>). Block devices are used for storing file systems. They are random access devices where data is transferred in blocks. Examples of block devices include hard and floppy disks. Character devices are any device that does not fall in the block category. Examples of character devices include serial and graphical input devices, for example, terminals and graphics tablets.</p><dd><p class="Body"><a name="85080"> </a>As discussed in earlier sections, the three main elements of the VxWorks I/O system are drivers, devices, and files. The following sections describe these elements in detail. The discussion focuses on character drivers; however, much of it is applicable for block devices. Because block drivers must interact with VxWorks file systems, they use a slightly different organization; see <a href="c-iosys9.html#85946"><i class="title">3.9.4 Block Devices</i></a>.</p></dl></dl><dl class="margin"><dd><p class="table" callout><table border="0" cellpadding="0" cellspacing="0"><tr valign="top"><td valign="top" width="40"><br><img border="0" alt="*" src="icons/note.gif"></td><td><hr><div class="CalloutCell"><a name="97378"><b class="symbol_UC"><font face="Helvetica, sans-serif" size="-1" class="sans">NOTE: </font></b></a>This discussion is designed to clarify the structure of VxWorks I/O facilities and to highlight some considerations relevant to writing I/O drivers for VxWorks. It is not a complete text on writing a device driver. For detailed information on this subject, see the <i class="title">Tornado BSP Developer's Kit User's Guide</i>.</div></td></tr><tr valign="top"><td></td><td><hr></td></tr><tr valign="middle"><td colspan="20"></td></tr></table></p callout><dl class="margin"><dd><p class="Body"><a name="85087"> </a><a href="c-iosys9.html#85091">Example 3-9</a> shows the abbreviated code for a hypothetical driver that is used as an example throughout the following discussions. This example driver is typical of drivers for character-oriented devices.</p><dd><p class="Body"><a name="85088"> </a>In VxWorks, each driver has a short, unique abbreviation, such as <b class="file">net</b> or <b class="file">tty</b>, which is used as a prefix for each of its routines. The abbreviation for the example driver is <i class="textVariable">xx</i>.</p></dl></dl><h4 class="EntityTitle"><a name="85091"><font face="Helvetica, sans-serif" size="-1" class="sans">Example 3-9: Hypothetical Driver</font></a></h4><dl class="margin"><dl class="margin"><dd><pre class="Code"><b><a name="85092">/************************************************************************* * xxDrv - driver initialization routine * * xxDrv() initializes the driver. It installs the driver via iosDrvInstall. * It may allocate data structures, connect ISRs, and initialize hardware. */ STATUS xxDrv () { xxDrvNum = iosDrvInstall (xxCreat, 0, xxOpen, 0, xxRead, xxWrite, xxIoctl); (void) intConnect (intvec, xxInterrupt, ...); ... }</a></b><dd> <b><a name="86852">/************************************************************************* * xxDevCreate - device creation routine * * Called to add a device called <name> to be serviced by this driver. Other * driver-dependent arguments may include buffer sizes, device addresses... * The routine adds the device to the I/O system by calling iosDevAdd. * It may also allocate and initialize data structures for the device, * initialize semaphores, initialize device hardware, and so on. */ STATUS xxDevCreate (name, ...) char * name; ... { status = iosDevAdd (xxDev, name, xxDrvNum); ... }</a></b><dd> <b><a name="86853">/************************************************************************* * The following routines implement the basic I/O functions. The xxOpen() * return value is meaningful only to this driver, and is passed back as an * argument to the other I/O routines. */</a></b><dd> <b><a name="93434">int xxOpen (xxDev, remainder, mode) XXDEV * xxDev; char * remainder; int mode; { /* serial devices should have no file name part */ if (remainder[0] != 0) return (ERROR); else return ((int) xxDev); } int xxRead (xxDev, buffer, nBytes) XXDEV * xxDev; char * buffer; int nBytes; ... int xxWrite (xxDev, buffer, nBytes) ... int xxIoctl (xxDev, requestCode, arg) ...</a></b><dd> <b><a name="86854">/************************************************************************* * xxInterrupt - interrupt service routine * * Most drivers have routines that handle interrupts from the devices * serviced by the driver. These routines are connected to the interrupts * by calling intConnect (usually in xxDrv above). They can receive a * single argument, specified in the call to intConnect (see intLib). */ VOID xxInterrupt (arg) ...</a></b></pre></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H3"><i><a name="85094">3.9.1 Drivers </a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="85095"> </a>A driver for a non-block device implements the seven basic I/O functions--<b class="routine"><i class="routine">creat</i></b><b>(</b> <b>)</b>, <b class="routine"><i class="routine">remove</i></b><b>(</b> <b>)</b>, <b class="routine"><i class="routine">open</i></b><b>(</b> <b>)</b>, <b class="routine"><i class="routine">close</i></b><b>(</b> <b>)</b>, <b class="routine"><i class="routine">read</i></b><b>(</b> <b>)</b>, <b class="routine"><i class="routine">write</i></b><b>(</b> <b>)</b>, and <b class="routine"><i class="routine">ioctl</i></b><b>(</b> <b>)</b>--for a particular kind of device. In general, this type of driver has routines that implement each of these functions, although some of the routines can be omitted if the functions are not operative with that device. </p><dd><p class="Body"><a name="85096"> </a>Drivers can optionally allow tasks to wait for activity on multiple file descriptors. This is implemented using the driver's <b class="routine"><i class="routine">ioctl</i></b><b>( )</b> routine; see <a href="c-iosys9.html#85695"><i class="title">Implementing select( )</i></a>.</p><dd><p class="Body"><a name="85100"> </a>A driver for a block device interfaces with a file system, rather than directly with the I/O system. The file system in turn implements most I/O functions. The driver need only supply routines to read and write blocks, reset the device, perform I/O control, and check device status. Drivers for block devices have a number of special requirements that are discussed in <a href="c-iosys9.html#85946"><i class="title">3.9.4 Block Devices</i></a>.</p><dd><p class="Body"><a name="85104"> </a>When the user invokes one of the basic I/O functions, the I/O system routes the request to the appropriate routine of a specific driver, as detailed in the following sections. The driver's routine runs in the calling task's context, as though it were called directly from the application. Thus, the driver is free to use any facilities normally available to tasks, including I/O to other devices. This means that most drivers have to use some mechanism to provide mutual exclusion to critical regions of code. The usual mechanism is the semaphore facility provided in <b class="library">semLib</b>.</p><dd><p class="Body"><a name="85106"> </a>In addition to the routines that implement the seven basic I/O functions, drivers also have three other routines:</p></dl><dl class="margin"><p class="listspace"><ul class="Bullet" type="disc"><li><a name="85107"> </a>An initialization routine that installs the driver in the I/O system, connects to any interrupts used by the devices serviced by the driver, and performs any necessary hardware initialization (typically named <i class="textVariable">xx</i><b class="routine"><i class="routine">Drv</i></b><b>(</b> <b>)</b>).</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="85109"> </a>A routine to add devices that are to be serviced by the driver (typically named <i class="textVariable">xx</i><b class="routine"><i class="routine">DevCreate</i></b><b>(</b> <b>)</b>) to the I/O system.</li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="85111"> </a>Interrupt-level routines that are connected to the interrupts of the devices serviced by the driver.</li></ul></p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="85114">The Driver Table and Installing Drivers</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="85115"> </a>The function of the I/O system is to route user I/O requests to the appropriate routine of the appropriate driver. The I/O system does this by maintaining a table that contains the address of each routine for each driver. Drivers are installed dynamically by calling the I/O system internal routine <b class="routine"><i class="routine">iosDrvInstall</i></b><b>(</b> <b>)</b>. The arguments to this routine are the addresses of the seven I/O routines for the new driver. The <b class="routine"><i class="routine">iosDrvInstall</i></b><b>(</b> <b>)</b> routine enters these addresses in a free slot in the driver table and returns the index of this slot. This index is known as the <i class="term">driver number</i> and is used subsequently to associate particular devices with the driver.</p><dd><p class="Body"><a name="85118"> </a>Null (0) addresses can be specified for some of the seven routines. This indicates that the driver does not process those functions. For non-file-system drivers, <b class="routine"><i class="routine">close</i></b><b>(</b> <b>)</b> and <b class="routine"><i class="routine">remove</i></b><b>(</b> <b>)</b> often do nothing as far as the driver is concerned. </p><dd><p class="Body"><a name="85121"> </a>VxWorks file systems (<b class="library">dosFsLib</b>, <b class="library">rt11FsLib</b>, and <b class="library">rawFsLib</b>) contain their own entries in the driver table, which are created when the file system library is initialized.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="85122">Example of Installing a Driver</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="85126"> </a><a href="c-iosys9.html#89802">Figure 3-2</a> shows the actions taken by the example driver and by the I/O system when the initialization routine <i class="textVariable">xx</i><b class="routine"><i class="routine">Drv</i></b><b>(</b> <b>)</b> runs.</p><dl class="margin">?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -