pal at cs.stanford.edu
Wed Mar 11 10:53:04 PDT 2009
As developers have started implementing standards on TinyOS, message_t
has started to show some limitations. The goal of message_t was to
allow software to pass messages between different AM link layers
without copying, and this involved several simplifying assumptions. As
systems need more complex link layers (e.g., more than one 15.4
addressing mode, security support, IPv6 on top of 15.4), some of the
design decisions have started to become problematic.
For example, message_t requires that the header, data, and footer be
allocated separately. Depending on your 15.4 addressing and other
options, the header can be anywhere from 3 to 30 bytes or so.
Correspondingly, the payload can be anywhere from 120 to 95 bytes or
so. While the two of them have, in combination, a maximum length
(125), you have to allocate the maximum of each of them separately,
leading to about a 20% waste (150 bytes).
This has led core to start looking at other message abstractions. It's
important to note that changing the underlying buffer abstraction used
by radio drivers does not mean we have to break AM-based software
compatibility: many of these issues are arising exactly because TinyOS
needs more than just AM. At the worst case, you just make a single
copy between the AM layer (message_t) and other buffer abstraction
that drivers and other stacks use.
Jan (TU Berlin) is going to send out one proposal he's come up with.
Stephen (Berkeley) also has some thoughts, and I encourage everyone to
examine the proposals. This is hopefully something that will change
for 2.1.1, or if more involved than anticipated, maybe a later version.
More information about the Tinyos-devel