oliverschmidt e5665fb968 The recent change turning uip_buf from an array to a pointer seems a quite heavyweight way to have the uip_buf alligned to a 32-bit boundary. Contiki is - still - supposed to be portable across a wide range of toolchains - therefore it i.e. intentionally doesn't use C99 features. From that perspective it seems questionable if all toolchains are able to optimize away the overhead imposed by an "unnecessary" indirection to access uip_buf - and uIP consists mostly of accesses to uip_buf. Even if the future is supposed to bring support for multiple uip_bufs which would turn the uip_buf pointer from a mere workaround to an neceesary element on can still presume that there will be targets with resources limited in a way prohibiting the use of several uip_bufs. So at least for those targets will still be a usecase for a "plain", not indirected uip_buf. ...

Therefore it seems reasonable to allow to stay with the "plain" uip_buf at compile-time.

2010-05-08 07:23:55 +00:00

..

mac

Adjusted the code so as to remove compilation warnings.

2010-04-30 22:18:12 +00:00

rime

Added check to not copy or create too large packets

2010-05-02 14:59:11 +00:00

rpl

bug fix: dag pointer may be NULL

2010-05-07 13:51:34 +00:00

dhcpc.c

…

dhcpc.h

…

hc.c

…

hc.h

…

neighbor-attr.c

…

neighbor-attr.h

…

neighbor-info.c

…

neighbor-info.h

…

netstack.c

…

netstack.h

…

psock.c

Adjusted formal parameter to single existing actual parameter.

2010-03-29 20:26:14 +00:00

psock.h

…

rawpacket-udp.c

…

rawpacket-udp.h

…

rawpacket.h

…

resolv.c

…

resolv.h

…

rime.h

…

sicslowpan.c

added const for the uip_buf pointer for more efficient and smaller uip code and fixed same construct for the sicslowpan code

2010-05-05 13:07:45 +00:00

sicslowpan.h

…

slipdev.c

…

slipdev.h

…

tcpdump.c

…

tcpdump.h

…

tcpip.c

added initialization of RPL

2010-05-01 13:04:31 +00:00

tcpip.h

…

uaodv-def.h

…

uaodv-rt.c

…

uaodv-rt.h

…

uaodv.c

…

uaodv.h

…

uip6.c

Adjusted UIP_CONF_EXTERNAL_BUFFER to apply to actual buffer only.

2010-05-07 20:45:16 +00:00

uip_arch.h

…

uip_arp.c

…

uip_arp.h

…

uip-debug.c

added uip-debug utilities

2010-04-30 13:20:57 +00:00

uip-debug.h

added uip-debug utilities

2010-04-30 13:20:57 +00:00

uip-ds6.c

…

uip-ds6.h

always include the RPL route state to allow compilation of rpl code

2010-05-03 14:12:03 +00:00

uip-fw-drv.c

…

uip-fw-drv.h

…

uip-fw.c

…

uip-fw.h

…

uip-icmp6.c

added icmp_send function and moved rpl input function signature

2010-04-30 13:22:21 +00:00

uip-icmp6.h

added icmp_send function and moved rpl input function signature

2010-04-30 13:22:21 +00:00

uip-nd6.c

moved prefix to avoid compiler warning

2010-03-26 15:12:57 +00:00

uip-nd6.h

…

uip-neighbor.c

…

uip-neighbor.h

…

uip-over-mesh.c

bugfix: refresh correct source route

2010-03-31 09:38:42 +00:00

uip-over-mesh.h

…

uip-split.c

…

uip-split.h

…

uip-udp-packet.c

…

uip-udp-packet.h

…

uip.c

The recent change turning uip_buf from an array to a pointer seems a quite heavyweight way to have the uip_buf alligned to a 32-bit boundary. Contiki is - still - supposed to be portable across a wide range of toolchains - therefore it i.e. intentionally doesn't use C99 features. From that perspective it seems questionable if all toolchains are able to optimize away the overhead imposed by an "unnecessary" indirection to access uip_buf - and uIP consists mostly of accesses to uip_buf. Even if the future is supposed to bring support for multiple uip_bufs which would turn the uip_buf pointer from a mere workaround to an neceesary element on can still presume that there will be targets with resources limited in a way prohibiting the use of several uip_bufs. So at least for those targets will still be a usecase for a "plain", not indirected uip_buf.

2010-05-08 07:23:55 +00:00

uip.h

The recent change turning uip_buf from an array to a pointer seems a quite heavyweight way to have the uip_buf alligned to a 32-bit boundary. Contiki is - still - supposed to be portable across a wide range of toolchains - therefore it i.e. intentionally doesn't use C99 features. From that perspective it seems questionable if all toolchains are able to optimize away the overhead imposed by an "unnecessary" indirection to access uip_buf - and uIP consists mostly of accesses to uip_buf. Even if the future is supposed to bring support for multiple uip_bufs which would turn the uip_buf pointer from a mere workaround to an neceesary element on can still presume that there will be targets with resources limited in a way prohibiting the use of several uip_bufs. So at least for those targets will still be a usecase for a "plain", not indirected uip_buf.

2010-05-08 07:23:55 +00:00

uiplib.c

…

uiplib.h

…

uipopt.h

…