giomba/nes-proj
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

doxygen: Tried to fix documentation (sicslowpan-doc.txt, uip6-doc.txt)

Browse Source 
This commit tries to also fix the documentations of sicslowpan and
uip6 to reflect the current code state. I’m not sure if everything
makes sense.

sicslowpan: There are still some references to HC01, can this be
replaced by HC06?

uip6: Section about timers has changed, is this correct?

Doxyfile: The documentations reference static functions, to link to 
them correctly EXTRACT_STATIC = YES is needed.



Congratulations you fixed 134 of doxygen's warnings (old: 134 new: 0).
This commit is contained in:
Tommy Sparber 2015-11-15 22:06:46 +11:00
parent 938d17576b
commit 8792ba16b3
3 changed files with 37 additions and 41 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/Doxyfile
View File

@ -427,7 +427,7 @@ EXTRACT_PACKAGE = NO
# included in the documentation. # included in the documentation.
# The default value is: NO. # The default value is: NO.
EXTRACT_STATIC = NO EXTRACT_STATIC = YES
# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) defined # If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) defined
# locally in source files will be included in the documentation. If set to NO # locally in source files will be included in the documentation. If set to NO

28
doc/sicslowpan-doc.txt
View File

@ -100,8 +100,8 @@ the link-layer addresses.
<b>Address Autoconfiguration</b><br> <b>Address Autoconfiguration</b><br>
The address autoconfiguration mechanism also depends on the format of The address autoconfiguration mechanism also depends on the format of
the link-layer address. The dependency is reflected in the the link-layer address. The dependency is reflected in the
#uip_netif_addr_autoconf_set function in #uip-netif.c. #uip_ds6_set_addr_iid function in uip-ds6.c.
\code \code
#if (UIP_LLADDR_LEN == 8) #if (UIP_LLADDR_LEN == 8)
memcpy(ipaddr->u8 + 8, lladdr, UIP_LLADDR_LEN); memcpy(ipaddr->u8 + 8, lladdr, UIP_LLADDR_LEN);
@ -157,28 +157,28 @@ the header 25 bytes long).
<b>Compression schemes</b><br> <b>Compression schemes</b><br>
The #SICSLOWPAN_CONF_COMPRESSION compilation option defines the The #SICSLOWPAN_CONF_COMPRESSION compilation option defines the
compression scheme supported. We support HC1, HC01, and IPv6 compression. compression scheme supported. We support HC1, HC06, and IPv6 compression.
HC1 and IPv6 compression are defined in RFC4944, HC01 in HC1 and IPv6 compression are defined in RFC4944, HC06 in
draft-hui-6lowpan-hc. What we call IPv6 compression means sending packets draft-hui-6lowpan-hc-06. What we call IPv6 compression means sending packets
with no compression, and adding the IPv6 dispatch before the IPv6 header.<br> with no compression, and adding the IPv6 dispatch before the IPv6 header.<br>
If at compile time IPv6 "compression" is chosen, packets sent will never If at compile time IPv6 "compression" is chosen, packets sent will never
be compressed, and compressed packets will not be processed at reception.<br> be compressed, and compressed packets will not be processed at reception.<br>
If at compile time either HC1 or HC01 are chosen, we will try to compress If at compile time either HC1 or HC06 are chosen, we will try to compress
all fields at sending, and will accept packets compressed with the all fields at sending, and will accept packets compressed with the
chosen scheme, as well as uncompressed packets.<br> chosen scheme, as well as uncompressed packets.<br>
Note that HC1 and HC01 supports are mutually exclusive. HC01 should soon Note that HC1 and HC06 supports are mutually exclusive. HC06 should soon
deprecate HC1. deprecate HC1.
<b>Compression related functions</b><br> <b>Compression related functions</b><br>
When a packet is received, the #input function is called. Fragmentation When a packet is received, the #input function is called. Fragmentation
issues are handled, then we check the dispatch byte: if it is IPv6, we issues are handled, then we check the dispatch byte: if it is IPv6, we
treat the packet inline. If it is HC1 or HC01, the corresponding treat the packet inline. If it is HC1 or HC06, the corresponding
decompression function (#uncompress_hdr_hc1 or #uncompress_hdr_hc01) decompression function (#uncompress_hdr_hc1 or #uncompress_hdr_hc06)
is called.<br> is called.<br>
When a packet needs to be sent, we try to compress it. If only the IPv6 When a packet needs to be sent, we try to compress it. If only the IPv6
compression support is enabled, we just add the IPv6 dispatch before the compression support is enabled, we just add the IPv6 dispatch before the
802.15.4 payload. If HC1 or HC01 support is enabled, we call the 802.15.4 payload. If HC1 or HC06 support is enabled, we call the
corresponding compression function (#compress_hdr_hc1 or #compress_hdr_hc01) corresponding compression function (#compress_hdr_hc1 or #compress_hdr_hc06)
to compress the packet as much as possible. to compress the packet as much as possible.
<b>HC1 comments</b><br> <b>HC1 comments</b><br>

48
doc/uip6-doc.txt
View File

@ -36,7 +36,7 @@ are part of the uIP IPv6 stack. A complete description can be found in the
corresponding IETF standards which are available at corresponding IETF standards which are available at
http://www.ietf.org/rfc.html. http://www.ietf.org/rfc.html.
\note The #NETSTACK_CONF_WITH_IPV6 compilation flag is used to enable IPv6. \note The NETSTACK_CONF_WITH_IPV6 compilation flag is used to enable IPv6.
It is also recommended to set #UIP_CONF_IPV6_CHECKS to 1 It is also recommended to set #UIP_CONF_IPV6_CHECKS to 1
if one cannot guarantee that the incoming packets are correctly formed. if one cannot guarantee that the incoming packets are correctly formed.
@ -144,10 +144,10 @@ messages are also described in uip-nd6.h although the actual code is in
uip-nd6-io.c. uip-nd6-io.c.
<b>Neighbor discovery structures </b><br> <b>Neighbor discovery structures </b><br>
We use the following %neighbor discovery structures (declared in uip-nd6.c): We use the following %neighbor discovery structures:
\li A <em>%neighbor cache</em> with entries of type #uip_nd6_neighbor \li A <em>%neighbor cache</em> with entries of type #uip_ds6_nbr_t declared in uip-ds6-nbr.c.
\li A <em>prefix list</em> with entries of type #uip_nd6_prefix \li A <em>prefix list</em> with entries of type #uip_ds6_prefix_t declared in uip-ds6.c.
\li A <em>default router list</em> with entries of type #uip_nd6_defrouter \li A <em>default router list</em> with entries of type #uip_ds6_defrt_t declared in uip-ds6-route.c.
Each of this structure has its own add, remove and lookup Each of this structure has its own add, remove and lookup
functions. To update an entry in a ND structure, we first do a lookup functions. To update an entry in a ND structure, we first do a lookup
@ -161,7 +161,7 @@ Determine the link-layer address of a %neighbor given its IPv6 address.\n
\li Neighbor unreachability detection\n \li Neighbor unreachability detection\n
Verify that a neighbor is still reachable via a cached link-layer Verify that a neighbor is still reachable via a cached link-layer
address.\n address.\n
-> send a NS (done in #uip_nd6_periodic). -> send a NS (done in #uip_ds6_neighbor_periodic).
\li Next-hop determination\n \li Next-hop determination\n
Map an IPv6 destination address into the IPv6 address of the %neighbor Map an IPv6 destination address into the IPv6 address of the %neighbor
to which traffic for the destination should be sent.\n to which traffic for the destination should be sent.\n
@ -170,18 +170,18 @@ choose a default router, else send directly (done in #tcpip_ipv6_output).
\li Router, prefix, and parameter discovery\n \li Router, prefix, and parameter discovery\n
Update the list of default routers, on-link prefixes, and the network Update the list of default routers, on-link prefixes, and the network
parameters.\n parameters.\n
-> receive a RA (see #uip_nd6_io_ra_input). -> receive a RA (see #ra_input).
\subsection autoconf Stateless Address Autoconfiguration (RFC 4862) \subsection autoconf Stateless Address Autoconfiguration (RFC 4862)
RFC 4862 defines two main processes: RFC 4862 defines two main processes:
\li Duplicate Address Detection (DAD)\n \li Duplicate Address Detection (DAD)\n
Make sure that an address the node wished to use is not already in use Make sure that an address the node wished to use is not already in use
by another node.\n by another node.\n
-> send a NS (done in #uip_netif_dad) -> send a NS (done in #uip_ds6_dad)
\li Address Autoconfiguration\n \li Address Autoconfiguration\n
Configure an address for an interface by combining a received prefix Configure an address for an interface by combining a received prefix
and the interface ID (see #uip_netif_addr_add). The interface ID is and the interface ID (see #uip_ds6_addr_add). The interface ID is
obtained from the link-layer address using #uip_netif_get_interface_id.\n obtained from the link-layer address using #uip_ds6_set_addr_iid.\n
-> Receive a RA with a prefix information option that has the -> Receive a RA with a prefix information option that has the
autonomous flag set. autonomous flag set.
@ -191,7 +191,7 @@ performed for this link-local address. Available routers are
discovered by sending up to #UIP_ND6_MAX_RTR_SOLICITATIONS RS discovered by sending up to #UIP_ND6_MAX_RTR_SOLICITATIONS RS
packets. Address autoconfiguration is then performed based on the packets. Address autoconfiguration is then performed based on the
prefix information received in the RA. The interface initialization is prefix information received in the RA. The interface initialization is
performed in #uip_netif_init. performed in #uip_ds6_init.
\subsection icmpv6 ICMPv6 (RFC 4443) \subsection icmpv6 ICMPv6 (RFC 4443)
We support ICMPv6 Error messages as well as Echo Reply and Echo Request We support ICMPv6 Error messages as well as Echo Reply and Echo Request
@ -213,22 +213,18 @@ The IPv6 stack (like the IPv4 stack) is a Contiki process
PROCESS(tcpip_process, "TCP/IP stack"); PROCESS(tcpip_process, "TCP/IP stack");
\endcode \endcode
In addition to the \ref mainloop "periodic timer" that is used by TCP, In addition to the \ref mainloop "periodic timer" that is used by TCP,
five IPv6 specific timers are attached to this %process: three IPv6 specific timers are attached to this %process:
\li The #uip_nd6_timer_periodic is used for periodic checking of the \li The #uip_ds6_timer_rs is use to delay the sending of Router Solicitations
%neighbor discovery structures.
\li The #uip_netif_timer_dad is used to properly paced the Neighbor
Solicitation packets sent for Duplicate Address Detection.
\li The #uip_netif_timer_rs is use to delay the sending of Router Solicitations
packets in particular during the router discovery %process. packets in particular during the router discovery %process.
\li The #uip_netif_timer_periodic is used to periodically check the \li The #uip_ds6_timer_periodic is used to periodically check the
validity of the addresses attached to the network interface. validity of the addresses attached to the network interface, to
properly paced the Neighbor Solicitation packets sent for
Duplicate Address Detection and for periodic checking of the
%neighbor discovery structures.
\li The #uip_reass_timer is used to time-out the fragment reassembly \li The #uip_reass_timer is used to time-out the fragment reassembly
%process. %process.
\n \n
Both #uip_nd6_timer_periodic and #uip_netif_timer_periodic run continuously.
This could be avoided by using callback timers to handle ND and Netif structures timeouts.
<HR> <HR>
\section compileflags Compile time flags and variables \section compileflags Compile time flags and variables
@ -249,8 +245,8 @@ NBR_TABLE_CONF_MAX_NEIGHBORS
\section buffers IPv6 Buffers \section buffers IPv6 Buffers
The IPv6 code uses the same \ref memory "single global buffer" as the The IPv6 code uses the same \ref memory "single global buffer" as the
IPv4 code. This buffer should be large enough to contain one IPv4 code. This buffer should be large enough to contain one
packet of maximum size, i.e., #UIP_LINK_MTU = 1280 bytes. When \ref packet of maximum size, i.e., #UIP_LINK_MTU = 1280 bytes. When
reass "fragment reassembly" is enabled an additional buffer of the reass "fragment reassembly" is enabled an additional buffer of the
same size is used. same size is used.
@ -258,7 +254,7 @@ The only difference with the IPv4 code is the per %neighbor buffering
that is available when #UIP_CONF_IPV6_QUEUE_PKT is set to 1. This that is available when #UIP_CONF_IPV6_QUEUE_PKT is set to 1. This
additional buffering is used to queue one packet per %neighbor while additional buffering is used to queue one packet per %neighbor while
performing address resolution for it. This is a very costly feature as performing address resolution for it. This is a very costly feature as
it increases the RAM usage by approximately #NBR_TABLE_CONF_MAX_NEIGHBORS * it increases the RAM usage by approximately NBR_TABLE_CONF_MAX_NEIGHBORS *
#UIP_LINK_MTU bytes. #UIP_LINK_MTU bytes.
<HR> <HR>
@ -314,7 +310,7 @@ link-layer function used to send a packet. Similarly, the link-layer
should call #tcpip_input when an IP packet is received. should call #tcpip_input when an IP packet is received.
The code corresponding to the desired link layer is selected at The code corresponding to the desired link layer is selected at
compilation time (see for example the #UIP_LL_802154 flag). compilation time (see for example the UIP_CONF_LL_802154 flag).
<HR> <HR>