[Tinyos-devel] message_t

[Philip Levis]

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.

Thanks,

Phil