+++ /dev/null
-<!-- Copyright (C) 2003 Red Hat, Inc. -->
-<!-- This material may be distributed only subject to the terms -->
-<!-- and conditions set forth in the Open Publication License, v1.0 -->
-<!-- or later (the latest version is presently available at -->
-<!-- http://www.opencontent.org/openpub/). -->
-<!-- Distribution of the work or derivative of the work in any -->
-<!-- standard (paper) book form is prohibited unless prior -->
-<!-- permission is obtained from the copyright holder. -->
-<HTML
-><HEAD
-><TITLE
->Calling graph for Transmission and Reception</TITLE
-><meta name="MSSmartTagsPreventParsing" content="TRUE">
-<META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
-"><LINK
-REL="HOME"
-TITLE="eCos Reference Manual"
-HREF="ecos-ref.html"><LINK
-REL="UP"
-TITLE="Generic Ethernet Device Driver"
-HREF="io-eth-drv-generic1.html"><LINK
-REL="PREVIOUS"
-TITLE="Upper Layer Functions"
-HREF="io-eth-drv-upper-api.html"><LINK
-REL="NEXT"
-TITLE="SNMP"
-HREF="net-snmp.html"></HEAD
-><BODY
-CLASS="SECT1"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->eCos Reference Manual</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="io-eth-drv-upper-api.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
->Chapter 46. Generic Ethernet Device Driver</TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="net-snmp.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="IO-ETH-CALL-GRAPH">Calling graph for Transmission and Reception</H1
-><P
->It may be worth clarifying further the flow of control in the transmit and
-receive cases, where the hardware driver does use interrupts and so DSRs to
-tell the “foreground” when something asynchronous has occurred.</P
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="IO-ETH-CALL-GRAPH-TX">Transmission</H2
-><P
-></P
-><OL
-TYPE="1"
-><LI
-><P
->Some foreground task such as the application, SNMP “daemon”,
-DHCP management thread or whatever, calls into network stack to send a
-packet, or the stack decides to send a packet in response to incoming
-traffic such as a “ping” or <SPAN
-CLASS="ACRONYM"
->ARP</SPAN
-> request.</P
-></LI
-><LI
-><P
->The driver calls the
-<TT
-CLASS="FUNCTION"
-><TT
-CLASS="REPLACEABLE"
-><I
->HRDWR</I
-></TT
->_can_send()</TT
->
-function in the hardware driver.</P
-></LI
-><LI
-><P
-><TT
-CLASS="FUNCTION"
-><TT
-CLASS="REPLACEABLE"
-><I
->HRDWR</I
-></TT
->_can_send()</TT
->
-returns the number of available "slots" in which it
-can store a pending transmit packet.
-If it cannot send at this time, the packet is queued outside the
-hardware driver for later; in this case, the hardware is already busy
-transmitting, so expect an interrupt as described below for completion
-of the packet currently outgoing.</P
-></LI
-><LI
-><P
->If it can send right now, <TT
-CLASS="REPLACEABLE"
-><I
->HRDWR</I
-></TT
->_send() is called.
-<TT
-CLASS="FUNCTION"
-><TT
-CLASS="REPLACEABLE"
-><I
->HRDWR</I
-></TT
->_send()</TT
-> copies the
-data into special hardware buffers, or instructs the hardware to
-“send that.” It also remembers the key that is associated with
-this tx request.</P
-></LI
-><LI
-><P
->These calls return … time passes …</P
-></LI
-><LI
-><P
->Asynchronously, the hardware makes an interrupt to say
-“transmit is done.”
-The ISR quietens the interrupt source in the hardware and
-requests that the associated DSR be run.</P
-></LI
-><LI
-><P
->The DSR calls (or <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->is</I
-></SPAN
->) the
-<TT
-CLASS="FUNCTION"
->eth_drv_dsr()</TT
-> function in the generic driver.</P
-></LI
-><LI
-><P
-><TT
-CLASS="FUNCTION"
->eth_drv_dsr()</TT
-> in the generic driver awakens the
-“Network Delivery Thread” which calls the deliver function
-<TT
-CLASS="REPLACEABLE"
-><I
->HRDWR</I
-></TT
->_deliver() in the driver.</P
-></LI
-><LI
-><P
->The deliver function realizes that a transmit request has completed,
-and calls the callback tx-done function
-<TT
-CLASS="FUNCTION"
->(sc->funs->eth_drv->tx_done)()</TT
->
-with the same key that it remembered for this tx.</P
-></LI
-><LI
-><P
->The callback tx-done function
-uses the key to find the resources associated with
-this transmit request; thus the stack knows that the transmit has
-completed and its resources can be freed.</P
-></LI
-><LI
-><P
->The callback tx-done function
-also enquires whether <TT
-CLASS="REPLACEABLE"
-><I
->HRDWR</I
-></TT
->_can_send() now says
-“yes, we can send”
-and if so, dequeues a further transmit request
-which may have been queued as described above. If so, then
-<TT
-CLASS="REPLACEABLE"
-><I
->HRDWR</I
-></TT
->_send() copies the data into the hardware buffers, or
-instructs the hardware to "send that" and remembers the new key, as above.
-These calls then all return to the “Network Delivery Thread”
-which then sleeps, awaiting the next asynchronous event.</P
-></LI
-><LI
-><P
->All done …</P
-></LI
-></OL
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="IO-ETH-CALL-GRAPH-RX">Receive</H2
-><P
-></P
-><OL
-TYPE="1"
-><LI
-><P
->Asynchronously, the hardware makes an interrupt to say
-“there is ready data in a receive buffer.”
-The ISR quietens the interrupt source in the hardware and
-requests that the associated DSR be run.</P
-></LI
-><LI
-><P
->The DSR calls (or <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->is</I
-></SPAN
->) the
-<TT
-CLASS="FUNCTION"
->eth_drv_dsr()</TT
-> function in the generic driver.</P
-></LI
-><LI
-><P
-><TT
-CLASS="FUNCTION"
->eth_drv_dsr()</TT
-> in the generic driver awakens the
-“Network Delivery Thread” which calls the deliver function
-<TT
-CLASS="REPLACEABLE"
-><I
->HRDWR</I
-></TT
->_deliver() in the driver.</P
-></LI
-><LI
-><P
->The deliver function realizes that there is data ready and calls
-the callback receive function
-<TT
-CLASS="FUNCTION"
->(sc->funs->eth_drv->recv)()</TT
->
-to tell it how many bytes to prepare for.</P
-></LI
-><LI
-><P
->The callback receive function allocates memory within the stack
-(eg. <SPAN
-CLASS="TYPE"
->MBUFs</SPAN
-> in BSD/Unix style stacks) and prepares
-a set of scatter-gather buffers that can
-accommodate the packet.</P
-></LI
-><LI
-><P
->It then calls back into the hardware driver routine
-<TT
-CLASS="REPLACEABLE"
-><I
->HRDWR</I
-></TT
->_recv().
-<TT
-CLASS="REPLACEABLE"
-><I
->HRDWR</I
-></TT
->_recv() must copy the data from the
-hardware's buffers into the scatter-gather buffers provided, and return.</P
-></LI
-><LI
-><P
->The network stack now has the data in-hand, and does with it what it will.
-This might include recursive calls to transmit a response packet.
-When this all is done, these calls return, and the
-“Network Delivery Thread”
-sleeps once more, awaiting the next asynchronous event.</P
-></LI
-></OL
-></DIV
-></DIV
-><DIV
-CLASS="NAVFOOTER"
-><HR
-ALIGN="LEFT"
-WIDTH="100%"><TABLE
-SUMMARY="Footer navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="io-eth-drv-upper-api.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="ecos-ref.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="net-snmp.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Upper Layer Functions</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="io-eth-drv-generic1.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->SNMP</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
projects / karo-tx-redboot.git / blobdiff