📄 if_eex.html
字号:
<html><head><!-- /vobs/wpwr/docs/vxworks/ref/if_eex.html - generated by refgen from if_eex.c --> <title> if_eex </title></head><body bgcolor="#FFFFFF"> <hr><a name="top"></a><p align=right><a href="libIndex.html"><i>VxWorks Reference Manual : Libraries</i></a></p></blockquote><h1>if_eex</h1> <blockquote></a></blockquote><h4>NAME</h4><blockquote> <p><strong>if_eex</strong> - Intel EtherExpress 16 network interface driver </p></blockquote><h4>ROUTINES</h4><blockquote><p><p><b><i><a href="./if_eex.html#eexattach">eexattach</a></i>( )</b> - publish the <b>eex</b> network interface and initialize the driver and device<br><b><i><a href="./if_eex.html#eexTxStartup">eexTxStartup</a></i>( )</b> - start output on the chip<br><p></blockquote><h4>DESCRIPTION</h4><blockquote><p>This module implements the Intel EtherExpress 16 PC network interface carddriver. It is specific to that board as used in PC 386/486 hosts.This driver is written using the device's I/O registers exclusively.<p></blockquote><h4>SIMPLIFYING ASSUMPTIONS</h4><blockquote><p>This module assumes a little-endian host (80x86); thus, no endianadjustments are needed to manipulate the 82586 data structures (little-endian).<p>The on-board memory is assumed to be sufficient; thus, no provision is madefor additional buffering in system memory.<p>The "frame descriptor" and "buffer descriptor" structures can be boundinto permanent pairs by pointing each FD at a "chain" of one BD of MTU size.The 82586 receive algorithm fills exactly one BD for each FD; it looks tothe NEXT FD in line for the next BD.<p>The transmit and receive descriptor lists are permanently linked intocircular queues partitioned into sublists designated by the <b>EEX_LIST</b>headers in the driver control structure. Empty partitions have NULL pointerfields. EL bits are set as needed to tell the 82586 where a partition ends.The lists are managed in strict FIFO fashion; thus the link fields are nevermodified, just ignored if a descriptor is at the end of a list partition.<p></blockquote><h4>BOARD LAYOUT</h4><blockquote><p>This device is soft-configured. No jumpering diagram is required.<p></blockquote><h4>EXTERNAL INTERFACE</h4><blockquote><p>This driver provides the standard external interface with the followingexceptions. All initialization is performed within the attach routine andthere is no separate initialization routine. Therefore, in the global interfacestructure, the function pointer to the <b><i>init</i>( )</b> routine is NULL.<p>There is one user-callable routine, <b><i><a href="./if_eex.html#eexattach">eexattach</a></i>( )</b>. For details on usage,see the manual entry for this routine.<p></blockquote><h4>EXTERNAL SUPPORT REQUIREMENTS</h4><blockquote><p>None.<p></blockquote><h4>SYSTEM RESOURCE USAGE</h4><blockquote><p>- one mutual exclusion semaphore<br> - one interrupt vector<br> - one watchdog timer.<br> - 8 bytes in the initialized data section (data)<br> - 912 bytes in the uninitialized data section (bss)<p>The data and bss sections are quoted for the MC68020 architecture and may varyfor other architectures. The code size (text) will vary widely betweenarchitectures, and is thus not quoted here.<p>The device contains on-board buffer memory; no system memory is requiredfor buffering.<p></blockquote><h4>TUNING HINTS</h4><blockquote><p>The only adjustable parameter is the number of TFDs to create in adapter buffermemory. The total number of TFDs and RFDs is 21, given full-frame bufferingand the sizes of the auxiliary structures. <b><i><a href="./if_eex.html#eexattach">eexattach</a></i>( )</b> requires at least<b>MIN_NUM_RFDS</b> RFDs to exist. More than ten TFDs is not sensiblein typical circumstances.<p></blockquote><h4>SEE ALSO</h4><blockquote><p><b><a href="./if_eex.html#top">if_eex</a></b>, <b><a href="./ifLib.html#top">ifLib</a></b><hr><a name="eexattach"></a><p align=right><a href="rtnIndex.html"><i>Libraries : Routines</i></a></p></blockquote><h1><i>eexattach</i>( )</h1> <blockquote></a></blockquote><h4>NAME</h4><blockquote> <p><strong><i>eexattach</i>( )</strong> - publish the <b>eex</b> network interface and initialize the driver and device</p></blockquote><h4>SYNOPSIS</h4><blockquote><p><pre>STATUS eexattach ( int unit, /* unit number */ int port, /* base I/O address */ int ivec, /* interrupt vector number */ int ilevel, /* interrupt level */ int nTfds, /* # of transmit frames (0=default) */ int attachment /* 0=default, 1=AUI, 2=BNC, 3=TPE */ )</pre></blockquote><h4>DESCRIPTION</h4><blockquote><p>The routine publishes the <b>eex</b> interface by filling in a network interfacerecord and adding this record to the system list. This routine alsoinitializes the driver and the device to the operational state.<p></blockquote><h4>RETURNS</h4><blockquote><p>OK or ERROR.<p></blockquote><h4>SEE ALSO</h4><blockquote><p><b><a href="./if_eex.html#top">if_eex</a></b>, <b><a href="./ifLib.html#top">ifLib</a></b><hr><a name="eexTxStartup"></a><p align=right><a href="rtnIndex.html"><i>Libraries : Routines</i></a></p></blockquote><h1><i>eexTxStartup</i>( )</h1> <blockquote></a></blockquote><h4>NAME</h4><blockquote> <p><strong><i>eexTxStartup</i>( )</strong> - start output on the chip</p></blockquote><h4>SYNOPSIS</h4><blockquote><p><pre>#ifdef BSD43_DRIVER static void eexTxStartup ( int unit )</pre></blockquote><h4>DESCRIPTION</h4><blockquote><p>Looks for any action on the queue, and begins output if there is anythingthere. This routine is called from several possible threads. Each will bedescribed below.<p>The first, and most common thread, is when a user task requests thetransmission of data. Under BSD 4.3, this will cause <b><i>eexOutput</i>( )</b> to be called, which will cause <b><i>ether_output</i>( )</b> to be called, which will cause this routine to be called (usually). This routine will not be called if <b><i>ether_output</i>( )</b> finds that our interface output queue is full. In this case, the outgoing data will be thrown out. BSD 4.4 uses a slightly differentmodel in which the generic <b><i>ether_output</i>( )</b> routine is called directly, followed by a call to this routine.<p>The second, and most obscure thread, is when the reception of certainpackets causes an immediate (attempted) response. For example, ICMP echopackets (ping), and ICMP "no listener on that port" notifications. Allfunctions in this driver that handle the reception side are executed in thecontext of <b><i><a href="./netLib.html#netTask">netTask</a></i>( )</b>. Always. So, in the case being discussed, <b><i><a href="./netLib.html#netTask">netTask</a></i>( )</b> willreceive these certain packets, cause IP to be stimulated, and cause thegeneration of a response to be sent. We then find ourselves following thethread explained in the second example, with the important distinction thatthe context is that of <b><i><a href="./netLib.html#netTask">netTask</a></i>( )</b>.<p>The third thread occurs when this routine runs out of TFDs and returns. Ifthis occurs when our output queue is not empty, this routine would typicallynot get called again until new output was requested. Even worse, if theoutput queue was also full, this routine would never get called again andwe would have a lock state. It DOES happen. To guard against this, thetransmit clean-up handler detects the out-of-TFDs state and calls thisfunction. The clean-up handler also runs from netTask.<p>Note that this function is ALWAYS called between an <b><i>splnet</i>( )</b> and an <b><i>splx</i>( )</b>.This is true because <b><i><a href="./netLib.html#netTask">netTask</a></i>( )</b>, and <b><i>ether_output</i>( )</b> take care ofthis when calling this function. Therefore, no calls to these spl functionsare needed anywhere in this output thread.</blockquote><h4>SEE ALSO</h4><blockquote><p><b><a href="./if_eex.html#top">if_eex</a></b></body></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -