c-iosys7.html

vxworks相关论文

</td>
</tr>
</table>
</p>
</p>
</dl>

</dl>

<font face="Helvetica, sans-serif" class="sans">
<h4 class="H3"><i><a name="84814">3.7.4  &nbsp;&nbsp;Network File System (NFS) Devices</a></i></h4>
</font>
<dl class="margin">

<dl class="margin">

<dd><p class="Body"><a name="84816"> </a>Network File System (NFS) devices allow files on remote hosts to be accessed with the NFS protocol. The NFS protocol specifies both <i class="term">client </i>software, to read files from remote machines, and <i class="term">server</i> software, to export files to remote machines. </p>
<dd><p class="Body"><a name="84821"> </a>The driver <b class="library">nfsDrv</b> acts as a VxWorks NFS client to access files on any NFS server on the network. VxWorks also allows you to run an NFS server to export files to other systems; see <i class="title">VxWorks Network Programmer's Guide: File Access Applications</i>l.</p>
<dd><p class="Body"><a name="84825"> </a>Using NFS devices, you can create, open, and access remote files exactly as though they were on a file system on a local disk. This is called <i class="term">network transparency</i>.</p>
</dl>

</dl>

<font face="Helvetica, sans-serif" class="sans">
<h4 class="H4"><i><a name="84827">Mounting a Remote NFS File System from VxWorks</a></i></h4>
</font>
<dl class="margin">

<dl class="margin">

<dd><p class="Body"><a name="84828"> </a>Access to a remote NFS file system is established by mounting that file system locally and creating an I/O device for it using <b class="routine"><i class="routine">nfsMount</i></b><b>(</b>&nbsp;<b>)</b>. Its arguments are (1)&nbsp;the host name of the NFS server, (2)&nbsp;the name of the host file system, and (3)&nbsp;the local name for the file system. </p>
<dd><p class="Body"><a name="84831"> </a>For example, the following call mounts <b class="file">/usr</b> of the host <b class="file">mars</b> as <b class="file">/vxusr</b> locally:</p>
<dl class="margin">

<dd><pre class="Code2"><b><a name="84832">nfsMount ("mars", "/usr", "/vxusr");</a></b></pre>
</dl>

<dd><p class="Body"><a name="84833"> </a>This creates a VxWorks I/O device with the specified local name (<b class="file">/vxusr</b>, in this example). If the local name is specified as <b class="symbol_UC">NULL</b>, the local name is the same as the remote name.</p>
<dd><p class="Body"><a name="84834"> </a>After a remote file system is mounted, the files are accessed as though the file system were local. Thus, after the previous example, opening the file <b class="file">/vxusr/foo</b> opens the file <b class="file">/usr/foo</b> on the host <b class="file">mars</b>.</p>
<dd><p class="Body"><a name="84835"> </a>The remote file system must be <i class="term">exported</i> by the system on which it actually resides. However, NFS servers can export only local file systems. Use the appropriate command on the server to see which file systems are local. NFS requires <i class="term">authentication</i> parameters to identify the user making the remote access. To set these parameters, use the routines <b class="routine"><i class="routine">nfsAuthUnixSet</i></b><b>(</b>&nbsp;<b>)</b> and <b class="routine"><i class="routine">nfsAuthUnixPrompt</i></b><b>(</b>&nbsp;<b>)</b>.</p>
<dd><p class="Body"><a name="84840"> </a>Select <b class="symbol_UC">INCLUDE_NFS</b> for inclusion in the project facility VxWorks view to include NFS client support in your VxWorks configuration; see <i class="title">Tornado User's Guide: Projects</i> for information on configuring VxWorks.</p>
<dd><p class="Body"><a name="84841"> </a>The subject of exporting and mounting NFS file systems and authenticating access permissions is discussed in more detail in <i class="title">VxWorks Network Programmer's Guide: File Access Applications</i>. See also the reference entries <b class="library">nfsLib</b> and <b class="library">nfsDrv</b>, and the NFS documentation from Sun Microsystems.</p>
</dl>

</dl>

<font face="Helvetica, sans-serif" class="sans">
<h4 class="H4"><i><a name="84847">I/O Control Functions for NFS Clients</a></i></h4>
</font>
<dl class="margin">

<dl class="margin">

<dd><p class="Body"><a name="84852"> </a>NFS client devices respond to the <b class="routine"><i class="routine">ioctl</i></b><b>(</b>&nbsp;<b>)</b> functions summarized in <a href="c-iosys7.html#84856">Table&nbsp;3-12</a>. The functions listed are defined in <b class="file">ioLib.h</b>. For more information, see the reference entries for <b class="library">nfsDrv</b> and for <b class="routine"><i class="routine">ioctl</i></b><b>(</b>&nbsp;<b>)</b> in <b class="library">ioLib</b>.<p class="table">
<h4 class="EntityTitle"><a name="84856"><font face="Helvetica, sans-serif" size="-1" class="sans">Table 3-12:&nbsp;&nbsp;I/O Control Functions Supported by <b class="library">nfsDrv</b></font></a></h4>

<table border="0" cellpadding="0" cellspacing="0">
<tr>
<td colspan="20">
<hr class="tablerule">
</td>
</tr>
<tr valign="middle">
<th rowspan="1" colspan="1">
<div class="CellHeading"><b><a name="84860"> </a><font face="Helvetica, sans-serif" size="-1" class="sans">Function</font></b></div>
</th>

<th rowspan="1" colspan="1">
<div class="CellHeading"><b><a name="84862"> </a><font face="Helvetica, sans-serif" size="-1" class="sans">Description</font></b></div>
</th>


</tr>
<tr>
<td colspan="20">
<hr class="tablerule2">
</td>
</tr>
<tr valign="top">
<td colspan=1 rowspan=1>
<div class="CellBody"><a name="84869"> </a><b class="symbol_UC">FIOFSTATGET</b> &nbsp;</div>
</td>
<td colspan=1 rowspan=1>
<div class="CellBody"><a name="84871"> </a>Get file status information (directory entry data).&nbsp;</div>
</td>

</tr>
<tr valign="top">
<td colspan=1 rowspan=1>
<div class="CellBody"><a name="84874"> </a><b class="symbol_UC">FIOGETNAME</b> &nbsp;</div>
</td>
<td colspan=1 rowspan=1>
<div class="CellBody"><a name="84876"> </a>Get the file name of the <i class="acronym_lc">fd</i>.&nbsp;</div>
</td>

</tr>
<tr valign="top">
<td colspan=1 rowspan=1>
<div class="CellBody"><a name="84879"> </a><b class="symbol_UC">FIONREAD</b> &nbsp;</div>
</td>
<td colspan=1 rowspan=1>
<div class="CellBody"><a name="84881"> </a>Get the number of unread bytes in the file.&nbsp;</div>
</td>

</tr>
<tr valign="top">
<td colspan=1 rowspan=1>
<div class="CellBody"><a name="84884"> </a><b class="symbol_UC">FIOREADDIR</b> &nbsp;</div>
</td>
<td colspan=1 rowspan=1>
<div class="CellBody"><a name="84886"> </a>Read the next directory entry.&nbsp;</div>
</td>

</tr>
<tr valign="top">
<td colspan=1 rowspan=1>
<div class="CellBody"><a name="84889"> </a><b>FIOSEEK</b> &nbsp;</div>
</td>
<td colspan=1 rowspan=1>
<div class="CellBody"><a name="84891"> </a>Set the current byte offset in the file.&nbsp;</div>
</td>

</tr>
<tr valign="top">
<td colspan=1 rowspan=1>
<div class="CellBody"><a name="84894"> </a><b class="symbol_UC">FIOSYNC</b> &nbsp;</div>
</td>
<td colspan=1 rowspan=1>
<div class="CellBody"><a name="84896"> </a>Flush data to a remote NFS file.&nbsp;</div>
</td>

</tr>
<tr valign="top">
<td colspan=1 rowspan=1>
<div class="CellBody"><a name="84899"> </a><b class="symbol_UC">FIOWHERE</b> &nbsp;</div>
</td>
<td colspan=1 rowspan=1>
<div class="CellBody"><a name="84902"> </a>Return the current byte position in the file.&nbsp;</div>
</td>

</tr>

<tr>
<td colspan="20">
<hr class="tablerule">
</td>
</tr>
<tr valign="middle">
<td colspan="20">

</td>
</tr>
</table>
</p>
</p>
</dl>

</dl>

<font face="Helvetica, sans-serif" class="sans">
<h4 class="H3"><i><a name="84909">3.7.5  &nbsp;&nbsp;Non-NFS Network Devices</a></i></h4>
</font>
<dl class="margin">

<dl class="margin">

<dd><p class="Body"><a name="84910"> </a>VxWorks also supports network access to files on the remote host through the Remote Shell protocol (RSH) or the File Transfer Protocol (FTP). These implementations of network devices use the driver <b class="library">netDrv</b>. When a remote file is opened using RSH or FTP, the entire file is copied into local memory. As a result, the largest file that can be opened is restricted by the available memory. Read and write operations are performed on the in-memory copy of the file. When closed, the file is copied back to the original remote file if it was modified.</p>
<dd><p class="Body"><a name="84912"> </a>In general, NFS devices are preferable to RSH and FTP devices for performance and flexibility, because NFS does not copy the entire file into local memory. However, NFS is not supported by all host systems.</p>
</dl>

</dl>

<font face="Helvetica, sans-serif" class="sans">
<h4 class="H4"><i><a name="84914">Creating Network Devices</a></i></h4>
</font>
<dl class="margin">

<dl class="margin">

<dd><p class="Body"><a name="84915"> </a>To access files on a remote host using either RSH or FTP, a network device must first be created by calling the routine <b class="routine"><i class="routine">netDevCreate</i></b><b>(</b>&nbsp;<b>)</b>. The arguments to <b class="routine"><i class="routine">netDevCreate</i></b><b>(</b>&nbsp;<b>)</b> are (1)&nbsp;the name of the device, (2)&nbsp;the name of the host the device accesses, and (3)&nbsp;which protocol to use: 0 (RSH) or 1 (FTP).</p>
<dd><p class="Body"><a name="84917"> </a>For example, the following call creates an RSH device called <b class="file">mars:</b> that accesses the host <b class="file">mars</b>. By convention, the name for a network device is the remote machine's name followed by a colon (<b>:</b>).</p>
<dl class="margin">

<dd><pre class="Code2"><b><a name="84918">netDevCreate ("mars:", "mars", 0);</a></b></pre>
</dl>

<dd><p class="Body"><a name="93625"> </a>Files on a network device can be created, opened, and manipulated as if on a local disk. Thus, opening the file <b class="file">mars:/usr/foo</b> actually opens <b class="file">/usr/foo</b> on host <b class="file">mars</b>.</p>
<dd><p class="Body"><a name="84920"> </a>Note that creating a network device allows access to any file or device on the remote system, while mounting an NFS file system allows access only to a specified file system.</p>
<dd><p class="Body"><a name="84921"> </a>For the files of a remote host to be accessible with RSH or FTP, permissions and user identification must be established on both the remote and local systems. Creating and configuring network devices is discussed in detail in <i class="title">VxWorks Network Programmer's Guide: File Access Applications </i>and in the reference entry for <b class="library">netDrv</b>.</p>
</dl>

</dl>

<font face="Helvetica, sans-serif" class="sans">
<h4 class="H4"><i><a name="84926">I/O Control Functions</a></i></h4>
</font>
<dl class="margin">

<dl class="margin">

<dd><p class="Body"><a name="84927"> </a>RSH and FTP devices respond to the same <b class="routine"><i class="routine">ioctl</i></b><b>(</b>&nbsp;<b>)</b> functions as NFS devices except for <b class="symbol_UC">FIOSYNC</b> and <b class="symbol_UC">FIOREADDIR</b>. The functions are defined in the header file <b class="file">ioLib.h</b>. For more information, see the reference entries for <b class="library">netDrv</b> and <b class="routine"><i class="routine">ioctl</i></b><b>(</b>&nbsp;<b>)</b>.</p>
</dl>

</dl>

<font face="Helvetica, sans-serif" class="sans">
<h4 class="H3"><i><a name="84932">3.7.6  &nbsp;&nbsp;Block Devices</a></i></h4>
</font>
<dl class="margin">

<dl class="margin">

<dd><p class="Body"><a name="84933"> </a>A <i class="term">block device</i> is a device that is organized as a sequence of individually accessible blocks of data. The most common type of block device is a disk. In VxWorks, the term <i class="term">block</i> refers to the smallest addressable unit on the device. For most disk devices, a VxWorks block corresponds to a <i class="term">sector</i>, although terminology varies.</p>
<dd><p class="Body"><a name="84934"> </a>Block devices in VxWorks have a slightly different interface than other I/O devices. Rather than interacting directly with the I/O system, block device support consists of low-level drivers that interact with a file system. The file system, in turn, interacts with the I/O system. This arrangement allows a single low-level driver to be used with various different file systems and reduces the number of I/O functions that must be supported in the driver. The internal implementation of low-level drivers for block devices is discussed in <a href="c-iosys9.html#85946"><i class="title">3.9.4&nbsp;Block Devices</i></a>.</p>
</dl>

</dl>

<font face="Helvetica, sans-serif" class="sans">
<h4 class="H4"><i><a name="84939">File Systems</a></i></h4>
</font>
<dl class="margin">

<dl class="margin">

<dd><p class="Body"><a name="84940"> </a>For use with block devices, VxWorks is supplied with file system libraries compatible with the MS-DOS (dosFs) and RT-11 (rt11Fs) file systems. In addition, there is a library for a simple raw disk file system (rawFs), which treats an entire disk much like a single large file. Also supplied is a file system that supports SCSI tape devices, which are organized so that individual blocks of data are read and written sequentially, and a file system that supports CD-ROM devices. Use of these file systems is discussed in <a href="c-filesys.html#84368"><i class="title">4.&nbsp;Local File Systems</i></a> in this manual. Also see the reference entries for <b class="library">dosFsLib</b>, <b class="library">rt11FsLib</b>, <b class="library">rawFsLib</b>, <b class="library">tapeFsLib</b>, and<b class="library"> cdromFsLib</b>.</p>
</dl>

</dl>

<font face="Helvetica, sans-serif" class="sans">
<h4 class="H4"><i><a name="87956">RAM Disk Drivers</a></i></h4>
</font>
<dl class="margin">

<dl class="margin">

<dd><p class="Body"><a name="87959"> </a>RAM drivers, as implemented in <b class="library">ramDrv</b>, emulate disk devices but actually keep all data in memory. Memory location and "disk" size are specified when a RAM device is created by calling <b class="routine"><i class="routine">ramDevCreate</i></b><b>(</b>&nbsp;<b>)</b>. This routine can be called repeatedly to create multiple RAM disks. </p>
<dd><p class="Body"><a name="87962"> </a>Memory for the RAM disk can be preallocated and the address passed to <b class="routine"><i class="routine">ramDevCreate</i></b><b>(</b>&nbsp;<b>)</b>, or memory can be automatically allocated from the system memory pool using <b class="routine"><i class="routine">malloc</i></b><b>(</b>&nbsp;<b>)</b>. </p>
<dd><p class="Body"><a name="87964"> </a>After the device is created, a name and file system (dosFs, rt11Fs, or rawFs) must be associated with it using the file system's device initialization routine or file system's make routine, for example, <b class="routine"><i class="routine">dosFsDevInit</i></b><b>(</b>&nbsp;<b>)</b> or <b class="routine"><i class="routine">dosFsMkfs</i></b><b>(</b>&nbsp;<b>)</b>. Information describing the device is passed to the file system in a <b class="symbol_UC">BLK_DEV</b> structure. A pointer to this structure is returned by the RAM disk creation routine.</p>
<dd><p class="Body"><a name="87965"> </a>In the following example, a 200KB RAM disk is created with automatically allocated memory, 512-byte sections, a single track, and no sector offset. The device is assigned the name <b class="symbol_UC">DEV1</b><b class="file">:</b> and initialized for use with dosFs.</p>
</dl>

<dl class="margin">

<dd><pre class="Code"><b><a name="87966">    BLK_DEV&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*pBlkDev; 
    DOS_VOL_DESC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*pVolDesc; 
    pBlkDev = ramDevCreate (0, 512, 400, 400, 0); 
    pVolDesc = dosFsMkfs ("DEV1:", pBlkDev);</a></b></pre>
</dl>

<dl class="margin">

<dd><p class="Body"><a name="87970"> </a>The <b class="routine"><i class="routine">dosFsMkfs</i></b><b>(</b>&nbsp;<b>)</b> routine calls <b class="routine"><i class="routine">dosFsDevInit</i></b><b>(</b>&nbsp;<b>)</b> with default parameters and initializes the file system on the disk by calling <b class="routine"><i class="routine">ioctl</i></b><b>(</b>&nbsp;<b>)</b> with the <b class="symbol_UC">FIODISKINIT</b>.</p>
<dd><p class="Body"><a name="87971"> </a>If the RAM disk memory already contains a disk image, the first argument to <b class="routine"><i class="routine">ramDevCreate</i></b><b>(</b>&nbsp;<b>)</b> is the address in memory, and the formatting arguments must be identical to those used when the image was created. For example:</p>
<dl class="margin">

<dd><pre class="Code2"><b><a name="87972">pBlkDev = ramDevCreate (0xc0000, 512, 400, 400, 0); 
pVolDesc = dosFsDevInit ("DEV1:", pBlkDev, NULL);</a></b></pre>
</dl>

<dd><p class="Body"><a name="84946"> </a>In this case, <b class="routine"><i class="routine">dosFsDevInit</i></b>(&nbsp;) must be used instead, because the file system already exists on the disk and does not require re-initialization. This procedure is useful if a RAM disk is to be created at the same address used in a previous boot of VxWorks. The contents of the RAM disk are then preserved. Creating a RAM disk with rt11Fs using <b class="routine"><i class="routine">rt11FsMkfs</i></b>(&nbsp;) and <b class="routine"><i class="routine">rt11FsDevInit</i></b>(&nbsp;) follows these same procedures. For more information on RAM disk drivers, see the reference entry for <b class="library">ramDrv</b>. For more information on file systems, see <a href="c-filesys.html#84368"><i class="title">4.&nbsp;Local File Systems</i></a>.</p>
</dl>

</dl>

<font face="Helvetica, sans-serif" class="sans">
<h4 class="H4"><i><a name="87977">SCSI Drivers</a></i></h4>
</font>
<dl class="margin">

<dl class="margin">

<dd><p class="Body"><a name="84947"> </a>SCSI is a standard peripheral interface that allows connection with a wide variety of hard disks, optical disks, floppy disks, tape drives, and CD-ROM devices. SCSI block drivers are compatible with the dosFs and rt11Fs libraries, and offer several advantages for target configurations. They provide:</p>
</dl>

<dl class="margin">

<ul class="DashSingle" type="circle"><li><a name="84949"> </a>local mass storage in non-networked environments</li></ul>
<ul class="DashSingle" type="circle"><li><a name="84950"> </a>faster I/O throughput than Ethernet networks</li></ul>
</dl>

<dl class="margin">

<dd><p class="Body"><a name="87986"> </a>The SCSI-2 support in VxWorks supersedes previous SCSI support, although it offers the option of configuring the original SCSI functionality, now known as SCSI-1. With SCSI-2 enabled, the VxWorks environment can still handle SCSI-1 applications, such as file systems created under SCSI-1. However, applications that directly used SCSI-1 data structures defined in <b class="file">scsiLib.h</b> may require modifications and recompilation for SCSI-2 compatibility.</p>
<dd><p class="Body"><a name="98140"> </a>The VxWorks SCSI implementation consists of two modules, one for the device-independent SCSI interface and one to support a specific SCSI controller. The <b class="library">scsiLib</b> library provides routines that support the device-independent interface; device-specific libraries provide configuration routines that support specific controllers (for example, <b class="library">wd33c93Lib</b> for the Western Digital WD33C93 device or <b class="library">mb87030Lib</b> for the Fujitsu MB87030 device). There are also additional support routines for individual targets in <b class="library">sysLib.c</b>.</p>
</dl>