[net2-wg] header format changes (?)

[Stephen Dawson-Haggerty]

The cc2420 radio stack will need a few small patches to accommodate both
tinyos active messages and non-tinyos 6lowpan messages.

The goal is to provide standard tinyos AM dispatch when the network byte in
a packet is TINYOS_6LOWPAN_NETWORK_ID, and a more low level 802.14.5-ish
interface when it is not.  That way IP stacks can wire to the 802.15.4
interface and get the packets they need, while other tinyos code using the
AM interface will still work.  My thought is that we should provide both of
these interfaces from ActiveMessageC, although we could potentially also
split them apart.

My proposal: change cc2420_header_t: remove the 'network' and 'type' fields,
and create a new
typedef struct {
  nxle_uint8_t network;
  nxle_uint8_t type;
} am_header_t;

The active message layer is now a dispatch layer on top of the lower-level
802.15.4-ish interface.
 pros: this is clean, and layering-wise the right thing to do
 cons: (1) this means that the 2-byte AM header is part of the payload
region of the message_t therefore, getMaximumPayload() will return
TOSH_DATA_LENGTH -2 , not TOSH_DATA_LENGTH
       also, (2) components attempting to access these two fields from the
cc2420 header struct will no longer compile.

grepping for code doing (2) didn't turn up anything in core; component's
__shouldn't__ be doing this...  (2) shouldn't matter so long as applications
are using getMaximumPayload and not just assuming it's TOSH_DATA_LENGTH,
although if they've optimized memory use to set TOSH_DATA_LENGTH to be
__exactly__ right it will break.

We could clearly also do this without changing the header; what I'm trying
to feel out here is how much this will really break, and how much we care
since code-wise this does feel like the right thing to do.

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/net2-wg/attachments/20090118/681d1456/attachment.htm