doxygen: Tried to fix documentation (sicslowpan-doc.txt, uip6-doc.txt)
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
parent
938d17576b
commit
8792ba16b3
|
|
@ -427,7 +427,7 @@ EXTRACT_PACKAGE = NO
|
|||
# included in the documentation.
|
||||
# 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
|
||||
# locally in source files will be included in the documentation. If set to NO
|
||||
|
|
|
|||
|
|
@ -100,8 +100,8 @@ the link-layer addresses.
|
|||
|
||||
<b>Address Autoconfiguration</b><br>
|
||||
The address autoconfiguration mechanism also depends on the format of
|
||||
the link-layer address. The dependency is reflected in the
|
||||
#uip_netif_addr_autoconf_set function in #uip-netif.c.
|
||||
the link-layer address. The dependency is reflected in the
|
||||
#uip_ds6_set_addr_iid function in uip-ds6.c.
|
||||
\code
|
||||
#if (UIP_LLADDR_LEN == 8)
|
||||
memcpy(ipaddr->u8 + 8, lladdr, UIP_LLADDR_LEN);
|
||||
|
|
@ -157,28 +157,28 @@ the header 25 bytes long).
|
|||
|
||||
<b>Compression schemes</b><br>
|
||||
The #SICSLOWPAN_CONF_COMPRESSION compilation option defines the
|
||||
compression scheme supported. We support HC1, HC01, and IPv6 compression.
|
||||
HC1 and IPv6 compression are defined in RFC4944, HC01 in
|
||||
draft-hui-6lowpan-hc. What we call IPv6 compression means sending packets
|
||||
compression scheme supported. We support HC1, HC06, and IPv6 compression.
|
||||
HC1 and IPv6 compression are defined in RFC4944, HC06 in
|
||||
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>
|
||||
If at compile time IPv6 "compression" is chosen, packets sent will never
|
||||
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
|
||||
all fields at sending, and will accept packets compressed with the
|
||||
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
|
||||
chosen scheme, as well as uncompressed packets.<br>
|
||||
Note that HC1 and HC01 supports are mutually exclusive. HC01 should soon
|
||||
deprecate HC1.
|
||||
Note that HC1 and HC06 supports are mutually exclusive. HC06 should soon
|
||||
deprecate HC1.
|
||||
|
||||
<b>Compression related functions</b><br>
|
||||
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
|
||||
treat the packet inline. If it is HC1 or HC01, the corresponding
|
||||
decompression function (#uncompress_hdr_hc1 or #uncompress_hdr_hc01)
|
||||
treat the packet inline. If it is HC1 or HC06, the corresponding
|
||||
decompression function (#uncompress_hdr_hc1 or #uncompress_hdr_hc06)
|
||||
is called.<br>
|
||||
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
|
||||
802.15.4 payload. If HC1 or HC01 support is enabled, we call the
|
||||
corresponding compression function (#compress_hdr_hc1 or #compress_hdr_hc01)
|
||||
compression support is enabled, we just add the IPv6 dispatch before the
|
||||
802.15.4 payload. If HC1 or HC06 support is enabled, we call the
|
||||
corresponding compression function (#compress_hdr_hc1 or #compress_hdr_hc06)
|
||||
to compress the packet as much as possible.
|
||||
|
||||
<b>HC1 comments</b><br>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
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
|
||||
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.
|
||||
|
||||
<b>Neighbor discovery structures </b><br>
|
||||
We use the following %neighbor discovery structures (declared in uip-nd6.c):
|
||||
\li A <em>%neighbor cache</em> with entries of type #uip_nd6_neighbor
|
||||
\li A <em>prefix list</em> with entries of type #uip_nd6_prefix
|
||||
\li A <em>default router list</em> with entries of type #uip_nd6_defrouter
|
||||
We use the following %neighbor discovery structures:
|
||||
\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_ds6_prefix_t declared in uip-ds6.c.
|
||||
\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
|
||||
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
|
||||
Verify that a neighbor is still reachable via a cached link-layer
|
||||
address.\n
|
||||
-> send a NS (done in #uip_nd6_periodic).
|
||||
-> send a NS (done in #uip_ds6_neighbor_periodic).
|
||||
\li Next-hop determination\n
|
||||
Map an IPv6 destination address into the IPv6 address of the %neighbor
|
||||
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
|
||||
Update the list of default routers, on-link prefixes, and the network
|
||||
parameters.\n
|
||||
-> receive a RA (see #uip_nd6_io_ra_input).
|
||||
-> receive a RA (see #ra_input).
|
||||
|
||||
\subsection autoconf Stateless Address Autoconfiguration (RFC 4862)
|
||||
RFC 4862 defines two main processes:
|
||||
\li Duplicate Address Detection (DAD)\n
|
||||
Make sure that an address the node wished to use is not already in use
|
||||
by another node.\n
|
||||
-> send a NS (done in #uip_netif_dad)
|
||||
-> send a NS (done in #uip_ds6_dad)
|
||||
\li Address Autoconfiguration\n
|
||||
Configure an address for an interface by combining a received prefix
|
||||
and the interface ID (see #uip_netif_addr_add). The interface ID is
|
||||
obtained from the link-layer address using #uip_netif_get_interface_id.\n
|
||||
and the interface ID (see #uip_ds6_addr_add). The interface ID is
|
||||
obtained from the link-layer address using #uip_ds6_set_addr_iid.\n
|
||||
-> Receive a RA with a prefix information option that has the
|
||||
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
|
||||
packets. Address autoconfiguration is then performed based on the
|
||||
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)
|
||||
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");
|
||||
\endcode
|
||||
In addition to the \ref mainloop "periodic timer" that is used by TCP,
|
||||
five IPv6 specific timers are attached to this %process:
|
||||
\li The #uip_nd6_timer_periodic is used for periodic checking of the
|
||||
%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
|
||||
three IPv6 specific timers are attached to this %process:
|
||||
\li The #uip_ds6_timer_rs is use to delay the sending of Router Solicitations
|
||||
packets in particular during the router discovery %process.
|
||||
\li The #uip_netif_timer_periodic is used to periodically check the
|
||||
validity of the addresses attached to the network interface.
|
||||
\li The #uip_ds6_timer_periodic is used to periodically check the
|
||||
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
|
||||
%process.
|
||||
\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>
|
||||
|
||||
\section compileflags Compile time flags and variables
|
||||
|
|
@ -249,8 +245,8 @@ NBR_TABLE_CONF_MAX_NEIGHBORS
|
|||
|
||||
\section buffers IPv6 Buffers
|
||||
The IPv6 code uses the same \ref memory "single global buffer" as the
|
||||
IPv4 code. This buffer should be large enough to contain one
|
||||
packet of maximum size, i.e., #UIP_LINK_MTU = 1280 bytes. When \ref
|
||||
IPv4 code. This buffer should be large enough to contain one
|
||||
packet of maximum size, i.e., #UIP_LINK_MTU = 1280 bytes. When
|
||||
reass "fragment reassembly" is enabled an additional buffer of the
|
||||
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
|
||||
additional buffering is used to queue one packet per %neighbor while
|
||||
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.
|
||||
|
||||
<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.
|
||||
|
||||
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>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue